Steven D'Aprano writes:
Ah, but that's because you're a Python programmer who has been seeped in the language for many, many years :-)
No, it's because I'm a Lisp programmer for twice as long, and know the differences among #'=, #'string=, #'equal, #'eql, and #'eq (the last is `is'`.
To most people, "is" and "equals" are synonyms,
In Python, this is a *bug*, and if it's not fixed, they are going to have a lot of trouble with mutable containers. Especially as default values for function arguments.
So for somebody who is expecting "is" to be a synonym for `==`, how do you explain what it actually is? You need to talk about the Python execution model,
I guess you need this if you want to explain how "x == None" can fail to do what you want, but that's independent of None's uniqueness.
how all values are objects, and that the reason that `x is None` always does the right thing
TOOWTDI violation. Python has both `==` and `is` *because* they do different things. What each does is a right thing. The programmer's problem is to learn what each does and when to use it.
but `x is []` doesn't is that None is a singleton, so that there is only one object that is None, but the empty list is not, there are many, many distinct empty lists.
I would avoid use of "singleton" personally, since it's also used to denote a *type* with only one member, and for many students (eg, all of mine) you would have to define it. I don't see what "None is a singleton, so that" adds to You need to talk about the Python execution model, how all values are objects, and that the reason that `x is None` always does the right thing but `x is []` doesn't is that there is only one object that is None, but the empty list is not, there are many, many distinct empty lists.
You might be able to avoid using the word "singleton",
I just did, or maybe I should say, you just did. ;-) Steve