Obsolesence of <> (fwd)

Alex Martelli aleaxit at yahoo.com
Fri Jun 1 12:10:34 CEST 2001


"James Logajan" <JamesL at Lugoj.Com> wrote in message
news:3B16D681.E12A4554 at Lugoj.Com...
> Alex Martelli wrote:
> [ Shows that Python complex numbers do not support ">" or "<" but
>   do support "<>" and states: ]
> > Here, I cannot write x>y, nor x<y, in 2.1 and later.  So, by your
> > reasoning, I shouldn't be able to write x<>y either, right?-)
>
> Well, that could also be taken as evidence that someone forgot to
implement
> default ">" and "<" operations for complex numbers, not that they can't be

"forgot" would clearly be a wrong inference: the error message
when you try to use these operators on complex numbers shows
that 'someone' very deliberately DECIDED not to guess at some
arbitrary ordering of complex numbers.  Given such hints as:
http://mail.python.org/pipermail/python-dev/2001-January/011755.html
I suspect the 'someone' may be one "van Rossum" guy, so you
may want to take the fight up with him...?


> against "<>" doesn't exactly endorse the horrible usage if "!=". At least
> proponents of "<>" can point to some pseudo mathematical justification for
> "<>". All the proponents of "!=" can point to for justification is the
usage

The "pseudo-mathematical" ideas being those based on < and > which
Lulu just proposed?  Well then, if those ideas have any worth, then,
GIVEN (as decided by the BDFL) that < and > don't apply, neither
must <>.  The only "justification" needed for != is: SOME inequality
operator is needed, and it must definitely not be <>, which WRONGLY
suggests analogies to < and >.  It was fine as long as < and > were
universally applicable in Python.  It's not fine now that they aren't.

"not =" would be fine IMHO (just as "is not" and "not in" are fine
operators today).  Presumably Guido's justification for "!=" rather
than "not =" is that making an operator by juxtaposing a keyword
and a non-alpha symbol looks bad -- operators should be (one or)
two keywords OR non-alpha.  Whatever -- the exact surface looks
don't matter all that much to me, anyway -- as long as whatever
symbol IS chosen suggests "NOT - EQUAL", which is exactly the
intended semantics, rather than "LESSER - GREATER", which ISN'T
(not given the way < and > work today in Python).

Besides, given the existence of "print >> blah", we're suffering
from a serious surfeit of "order characters not meaning order"
already:-).  Let's abate it wherever we can...:-)


> Or better yet: just accept that neither "<>" and "!=" should be obsoleted
> and let this issue die a deserved death. Somebody should inform Guido.

"There should be one, and ideally only one, obviously correct way
to do something".  Having two entirely synonymous operators is
unPythonic.  It's an ideal, of course, not a practical reality --
pow(x,y) vs x**y, apply(spam,args) vs spam(*args), etc, shows that
multiple ways to "do something" can and will survive in Python
(particularly for legacy/historical reasons).  It's still a worthy
ideal to aim at, in my humble opinion.


Alex






More information about the Python-list mailing list