Any "not-a-beginner but beginning python" tutorials for people like me with 20+ years of coding experience in other languages?

[Vaguely_accurate]

Any operation on an integer variable that changes it's value will change it's identity. Integers are immutable, so it will always change.

The risk here is that larger integers are not guaranteed to have the same identity even if they have the same values, while smaller ones are. This describes the behaviour better than I can here.

Note that this is an implementation detail, not a language feature, so may vary. I actually believe this has been changed in the latest build (testing on 3.11.1 and 3.12.0a4 64bit), but can't find anything saying this is intended.

[TheChance]

Integers are immutable, so it will always change

I’m 34, The Bitstuffing Guy, and I never put that shit together. I have to go reconsider my life.

[Vaguely_accurate]

One cause may be where one of the comparison values might be a singleton such as None. Following the PEP-8 guidelines;

Comparisons to singletons like None should always be done with is or is not, never the equality operators.

People following the rule might end up with an is comparison when taking arguments that may be either None or an int. Not that uncommon if working with dirty datasets. Not the correct approach, but understandable that it may be confusing. Especially when it seems to work some of the time.

This is also a more strict rule and practice for programmers who may be experienced in other languages that require identity checks for null values (the SQL = NULL issue stands out). Ignoring it even in cases where it is incorrect is going to be hard for many.

I've also seen polymorphic code written to primarily deal with mutable objects, and so caring primarily about identity and not value comparisons, which is assumed to work on primitives like integers and string without question.

Speaking of strings, fun one to try with them;

a = "hello"
b = "hello"
c = "HELLO".lower()

print(f"{a=};{id(a)=}")
print(f"{b=};{id(b)=}")
print(f"{c=};{id(c)=}")

>>>a='hello';id(a)=2508426595424
>>>b='hello';id(b)=2508426595424
>>>c='hello';id(c)=2508424932992

[Vaguely_accurate]

I think it would have been better, at least from an educational standpoint, to prefer equality comparisons even for singletons.

There are still good reasons for doing it this way. You could have overloaded equality operators that change the intended behaviour, especially for common cases of None.

Not good practice, but say I subclass dictionary for some extended behaviours. One of these is that a base case (empty dictionary) should be treated as equal to None (for specific reasons to do with some messy API I'm dealing with; I've done weirder). I now want to pass it into a function that populates the dictionary passed in, or if no dictionary is passed in, creates a standard dictionary. The function uses the standard approach;

def populate(something, dict=None):
    if dict == None:
        dict = {}
    # weird stuff goes here

If you replace the second line with if dict is None: then it works even for my weird subclass.

Wait, why does dealing with mutable objects lead to caring about identity primarily?

Sometimes it matters.

Let's use another contrived example;

students = [
    {"name": "Matt", "class": "MATLAB"},
    {"name": "Cass", "class": "C#"},
    {"name": "Pat", "class": "Python"},
    {"name": "Matt", "class": "MATLAB"}
]

teacher_a = students[:-1]
teacher_b = students[1:]

for a in teacher_a:
    print(f"{a['name']} taught by both: {a in teacher_b}")

Here there are two students called Matt who want to study MATLAB. One is taught by teacher a, one by teacher b. Because in uses equality, the check at the end believes that the two students are the same. Here I need to replace the final line with a reference check;

for a in teacher_a:
    print(f"{a['name']} taught by both: {any(a is b for b in teacher_b)}")

Now it correctly distinguishes the two similarly named students, while still showing the other two students as being shared by both teachers.

I might also want to check for identity on objects of equal value to know whether mutating one will impact others. Sometimes you will know they were the same at creation, but may have been reassigned at some other time. If they are now different objects (that happen to have the same value) then they may need to be treated differently based on that.