No; it's not about precedence at all. It's about semantics of chained comparisons, which is not what you'd expect in Python.

The syntax works exactly like it's supposed to. "is" is an alias for "==". This kind of chained comparison makes code much more readable. This contrived example which I never encountered as a practical issue not withstanding.

I think you need to brush up on Python...

>>> x = 25 * 37

>>> y = 25 * 37

>>> x is y

False

>>> x == y

True

From my understanding, '==' checks for equality and 'is' checks that the variables reference the same address.

OK this is truly weird:

  >>> a=16
  >>> a*a is a*a
  True
  >>> a=17
  >>> a*a is a*a
  False

WTF

CPython interns the integers between -5 and 256.

See https://stackoverflow.com/questions/306313/is-operator-behav... for some discussion and further related links.

I guess it's ok if you are aware of it but this can be a source of bugs: let's say you're not aware of this "feature" and you are in the middle of writing some code and want to know whether A is A always evaluates to true for integers. So you fire up Python and type "10 is 10" which gives True. ...

Using 'is' on integers raises a SyntaxWarning in 3.8+

That's why you should read the spec and not guess a function's definition from one example.

Otherwise you'll end up thinking that almost everything is simply an alias for constant True or 0 or Error, by popping in 0 to any operator you check.

No. Imho, a good language designer will make it possible to learn the language incrementally without surprises. For example, a tutorial on a language should not start with "please read the spec first or you may encounter some awkward and counter-intuitive behavior in areas you thought you had already mastered".

At the Python (rather than CPython implementation) level, the explanation is “is is object identity not value equality, and there is no guarantee that equal integers share object identity.”

At the CPython level, you can explain it in terms of the particular range of small integers that are interned and thus are guaranteed within particular CPython versions to share object identity when they have value equality.

But just knowing that is identity and == is equality is mostly enough to use them correctly.

Maybe also delete or reply to your previous commented in which you made strong assertions of wrong facts.

Maybe you should stick to assembly?

“==“ is not an alias of “is”, they behave quite differently.

`x is y` is an alias for `id(x) == id(y)`.

To see that this is not about precedence, evaluate the following:

  >>> True == False is False
  False
  >>> False == True is False
  False

Or think about it for a moment and realize that it would be True with either precedence if interpreted as expected.

Or read the very first part of the linked page that shows:

  >>> (True == False) is False
  True
  >>> True == (False is False)
  True

Would I be correct in avoiding "is" for any simple data types, and only using it for objects?

Integers are not simple data types in python. https://docs.python.org/2/c-api/int.html#PyInt_FromLong

You'd be correct to use 'is' to mean 'is', and '==' to mean '==', following their definitions.

It's idiomatic to use it for comparisons with the value `None`, which is a singleton so it's always that one.

Other than that, just don't use `is`.

See the comment by lonelappde, but note that the example under discussion here is actually not about `is` vs. `==` either.

Yes. By the time I realised my second example is redundant, it was already too late to edit the comment. Thanks for clarifying.