not in

[Alex Martelli]

rihad wrote:
        ...
>>Ah, just like, say, unary-plus (strictly non-necessary), binary
>>minus (non-necessary given the presence of unary-minus and binary
>>plus), and the backquote operator `...` (non-necessary given the
>>existence of builtin function repr).
> 
> All of the above are OK with me since I see them as funny ways to call
> functions back from C++. Aliases and syntactic sugar are cool, but

Not necessarily: it takes flair, which Guido has, to decide which
technically redundant operators to leave in.  You seem to base
your feelings strictly with analogies with C++ -- does this seem
like a sensible criterion to you, in the abstract?

Why should it be OK to have both > and <=, even though
(a <= b) is always identical to not (a > b), but somehow not ok
to have both is and is not, because (a is not b) is always
identical to not (a is b)?  Etc, etc, for all the other redundant
cases above listed.  What other criterion besides "to THAT one
I was used in C++" are you applying?

> still, not in/is not feels different... YMMV, after all, it's just a
> matter of style.

Python's style is a careful blend of simplicity and readability --
whether it works for you, of course, IS a subjective judgment,
in the end, but at least some of Python's stylistic choices are,
it seems, based on actual usability studies (dating back to the
times of ABC, Python's predecessor), thus, presumably, they
are meant to work optimally for most.

>>For example, most readers will find:
>>    a - b
>>more readable than
>>    a + -b
>>even though they're obviously equivalent, semantically.
> 
> AOL!

Is that AOL as in AOL Time Warner, or what?  Again I miss
your point.


Alex