not in

Alex Martelli aleax at aleax.it
Mon Jan 21 15:26:55 EST 2002


rihad wrote:
        ...
>>Sure, "not in" is not a keyword -- it's the combination of two
>>keywords (into one operator),
> 
> But its semantics are those of a /single/ keyword.

Very few keywords are operators, and very few operators are
keywords.  It's therefore more correct to say that the semantics
of operator 'not in' are the semantics of an operator (albeit
rather obviously redundant).

Otherwise you might as well say, for example, that the semantics
of operator <= are "those of a /single/ character", given that most
non-augmented operators are indeed lexically corresponding to
a single characters (while you sem to fixate on those lexically
corresponding to a single keyword instead).


>> Why should
>>Python invent new single-keywords, when pair of keywords can
>>combine readably and efficiently?  I keep missing your point.
> 
> If it's all about readability, Python should require `is' after `if',
> as in if x is in sequence

Why would the addition of redundant noisewords help readability
at all?  That's (roughly) what Cobol attempted, and the consensus
today is that such noisewords don't achieve that purpose.  Your
proposed construct would further risk masking errors, by being
quite close to "if x is sequence".


> I'm not advocating is_not/not_in, and I don't count the equivalence of
> x not in s/not (x in s) as a flaw - it's a decision, after all :) As
> someone else noted, the former form even helps the compiler to
> generate better code, which is all good. Perhaps that was the original
> intent of the `not in' "keyword".

Missing Guido, Tim to channel him, or careful research, we can only
guess, but my guess is "definitely not": identity and non-identity
testing is, I think, rare enough in tight loops, that no particular effort
to optimize it by a little bit seems worthwhile, given Python's slant.
On the other hand, optimizing readability (at no cost whatsoever, and
without any side effects, except, apparently, that of perturbing you)
appears definitely most Pythonic to me.


Alex




More information about the Python-list mailing list