views:

258

answers:

3

I think if I understand correctly, a <> b is the exact same thing functionally as a != b, and in Python not a == b, but is there reason to use <> over the other versions? I know a common mistake for Python newcomers is to think that not a is b is the same as a != b or not a == b.

  1. Do similar misconceptions occur with <>, or is it exactly the same functionally?
  2. Does it cost more in memory, processor, etc.
+11  A: 

<> in Python 2 is an exactly synonym for != -- no reason to use it, no disadvantages either except the gratuitous heterogeneity (a style issue). It's been long discouraged, and has now been removed in Python 3.

Alex Martelli
Ah, gone in 3 is a good enough reason for me. If Guido didn't like it, I don't either :) (although I assume there's support for this in 2 to 3).
orokusaki
You can find out for yourself at the new Python Translation Party: http://www.pythontranslationparty.appspot.com/6002/ It runs your code successively through 2to3 and 3to2, trying to find equilibrium.
jcdyer
@jcd thanks. That's a nifty tool.
orokusaki
It made sense to remove it. After all "<>" original meant "not equals" in the sense of "less than or greater than". But "<" and ">" have no meaning for objects that have not obvious orderinh. "!=" means explicitly "not =".
DavidG
A: 

you shouldn't use <> in python.

SilentGhost
This is a terrible answer. It gives no details, is not self explanatory, and is mildly rude.
Sean Nyman
@Sean: this question doesn't need any explanation, `<>` was obsolete for **10 years**. It's clearly state in each version of Python docs dating back to Python 2.0. There is no need to bother oneself with differences that it might have with `!=` operator. Don't use it: no problem to discuss.
SilentGhost
@SilentGhost: If you don't think there's anything to discuss then simply don't post an 'answer'. You could have easily justified your position but instead wonder why you get downvoted when your answer simply doesn't address the question at all.
Scott Griffiths
@Scott: **it's not a real question**. There is no need what so ever to wonder when one should use this obsolete operator and what might be the risk. It's a simple truth reiterated in **every Python doc in the last 10** years that if you learn not to use it you'd be better off. I perfectly see how everyone is willing to jump on PC bandwagon, but really there is not need to have this question at all: if docs tell me not to do something, I trust them, there aren't too many evil people among Python committers.
SilentGhost
Anyone coming across the `<>` operator for the first time in old Python code would legitimately question its usage. Yes, they could look it up in any Python doc for the last ten years, or now they could look it up on S.O. too. But I'm not trying to say it's a great question, just that you gave a very bad answer to it.
Scott Griffiths
Indeed completely nonsensical musing of Mark is so much better answer than mine.
SilentGhost
@Silent How was it "not a question"? You might be familiar with this: http://www.python.org/dev/peps/pep-0008/ It's the Python style guide, which is updated (last update was last year), and it mentions <> as an operator (where recommending single space before and after). I never can understand your hostility. I even upvoted your answer (because it seems to be right according to Alex who further expanded on the idea (and since Alex's book partly taught me Python, I take what he says without needing a grain of salt)).
orokusaki
+7  A: 

Just a pedantic note: the <> operator is in some sense misnamed (misdenoted?). a <> b might naturally be interpreted as meaning a < b or a > b (evaluating a and b only once, of course), but since not all orderings are total orderings, this doesn't match the actual semantics. For example, 2.0 != float('nan') is true, but 2.0 < float('nan') or 2.0 > float('nan') is false.

The != operator isn't subject to such possible misinterpretation.

For an interesting take (with poetry!) on the decision to drop <> for Python 3.x, see Requiem for an operator.

Mark Dickinson
Voted up, it was what I was trying to say in my own answer. I deleted it.
Kaltezar
Are you actually saying that `<>` is somehow related to `<` or `>`? And yet, you don't argue that `>>` or `<<` is *also* related to `>` or `<`? Why is one pair of characters (`<>`) magically related to `<` or `>`, yet other pairs of characters (`<<`,`>>`) not magically related? I don't get what you're saying. Can you clarify this?
S.Lott
No, I'm not; but it's a fairly plausible (mis)interpretation, and it fits with the definitions of `<=` and `>=`. I don't see the same risk of misinterpretation with `<<` and `>>`, but maybe that's just me.In similar vein, I seem to recall that IEEE 754 (the 2008 version) gives `<>?` as a possible spelling for the not-equal operation, to make the point that it includes the 'unordered' case as well as the 'less-than' and 'greater-than' cases.
Mark Dickinson
In fact, I don't really see much risk of misinterpretation at all. But this is the only concrete reason (however trivial) that I've ever seen for choosing one over the other.
Mark Dickinson
@Mark Dickinson: "fairly plausible"? I'd go for "egregious" or "hopelessly confused". Punctuation marks are heavily reused, and assigning some "inherent" meaning to ">" or "<" seems really odd to me. But maybe that's just 35 years of programming in too many languages that makes me unable to see any "inherent" meaning in any punctuation mark.
S.Lott
@S.Lott: I agree the connection is tenuous. It's not my own argument, though. Just for fun, check the link I added to the question above.
Mark Dickinson