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?