Ivan Pozdeev via Python-Dev wrote:

(while "<>" reads "less or greater" which is mathematically not equivalent to that: not everything has a defined ordering relation.

I think this is a silly argument against "<>". If we're going to try to assign meaning to individual characters in an operator, we could equally well say that "!" on its own should mean "not", which it doesn't in Python. Whereas "~" does, kind of, so "not equal" should be spelled "~=".

"<>" draws from BASIC AFAIK which was geared towards regular users who don't deal with advanced mathematics.)

Criticising something because it comes from BASIC smacks of snobbery. Anyway, it's also used by a number of entirely respectable languages such as Pascal and SQL. And what proportion of Python users deal with advanced mathematics? -- Greg

.... I'd just like to point out that given the existence of float NANs, there's a case to be made for having separate <> and != operators with != keeping the "not equal" meaning and the <> operator meaning literally "less than, or greater than".

py> NAN != 23 True py> NAN < 23 or NAN > 23 False

(I'm not making the case for this, just pointing out that it exists...)

There would be precedent too: at least one of Apple's SANE maths libraries back in the 1990s had a full set of NAN-aware comparison operators including IIRC separate "not equal" and "less than or greater than" comparisons.

But I think this is a corner of IEEE-754 esoterica that probably doesn't need to be a builtin operator :-)

The 754 standard's section 5.7 (Comparisons) defines 26(!) distinct comparison predicates. I bet SANE supplied all of them - and quite

[Steven D'Aprano] possibly nothing else in the world ever bothered (the standard _required_ only a relative few of them). I never had the slightest interest in garbaging-up Python with syntax for all those, so never even mentioned it in the early days. My secret plan ;-) was that if someone agitated for it enough to sway Guido, I'd add a math.ieee_compare(x, y, raise=False) function that returned one of the four bit constants IEEE_(LESS, EQUAL, GREATER, UNORDERED} (with values 1, 2, 4, 8), and raised some spelling of "invalid operation" iff `raise` was True and at least one of the comparands was a NaN. That's enough to build any of the standard's predicates (and a few more essentially useless ones, like "always true"). Then, e.g., for your <> above def "<>"(x, y): return ieee_compare(x, y) & (IEEE_LESS | IEEE_GREATER) != 0 and != above would add IEEE_UNORDERED to the bits checked in that. Then it's equal easy to build oddballs like "unordered or greater" and "only equal but raise an exception if a NaN is compared" too. I've been quite relieved that, after all these years, nobody else seemed to care about this either :-)