Obsolesence of <>

[Lulu of the Lotus-Eaters]

> It is very easy to read "<>" as "is less than or greater than" on the
> analogy of ">=" reading "is greater than or equal to."  Since all Python
> values can be compared, every two unequal things are indeed less than or

"Alex Martelli" <aleaxit at yahoo.com> wrote:
| Sorry, you're behind the times:
|
| Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
| Type "copyright", "credits" or "license" for more information.
| Alternative ReadLine 1.1 -- Copyright 2001, Chris Gonnerman
| >>> x=2+3j
| >>> y=5+8j
| >>> x<y
| Traceback (most recent call last):
|   File "<stdin>", line 1, in ?
| TypeError: cannot compare complex numbers using <, <=, >, >=
|
| 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?-)

Yeah.  I missed this change.  It does reduce the consistency of the
iconography.  But I still think that the "<>" spelling looks more
intuitive than the "!=" spelling by way of its nonetheless greater
consistency with the spelling of other operators, as discussed
previously.

In the end, spelling is arbitrary, of course.  But having families of
corresponding spellings for corresponding semantics makes it easier to
remember a language, and to teach it.

FWIW.  I'm not really sure I like the change Alex points to.  It makes
something like the below fail:

  l = [(1+1j),(2-2j),Klass(),Klass(),Klass,5,4,3,'c','b','a']
  l.sort()

In a list like this, many of the comparisons have no particular meaning.
I have no idea whether an instance of Klass is more than a complex
number.  And in most cases, I don't even have any idea whether one
instance is meaningfully greater than another.  But it is nice to have
everything have some arbitrary inequality relation in order to create
partial orderings on the subsets of things that really do have an order.
It makes perfect sense to me to want the numbers and strings to occur in
order, even while not caring exactly -where- in the sorted list they
occur as a sublist.

Is l.sort() a special case that avoids the non-comparison, btw?  If so,
substitute similar generic comparisons.  I don't have 2.1 handy to try
out the example.

Yours, Lulu...