In fairness to Nick, he is not talking about the real world. Nick is
talking about the hot-house environment of *education*, where fragile
newbies are generally protected from real world issues.

Let me unpack this just a teeny bit. We don't need to think of the students as fragile. Think of it as where the minutes go.

Like why is Java worse? You are trying to explain about comparisons, and you need like 30 minutes for Java where the number of different required comparison facilities is big, and it just looks needlessly complicated. What is the problem with that? Think of it this way: I wanted to talk about *algorithms* and solving real problems .. like those are the best uses of lecture time and examples. If the language injects something that you feel is not such a great use of time, you notice that those minutes are taken away from the actual course goals.

Now for Python, == vs. is nothing like that bad. Both == and is are sensible, necessary parts of the language, I would just prefer to talk about == earlier and is later. Of the two, == is the no-brainer one when the students just have ints and strings, and no-brainer is what you want in week 2.

For teaching, you are not just identifying the 500 important things they need to know. To teach artfully, you are trying to think of an ordering, layering on 50 new things each week, where the subest achieved each week is internally coherent and you can do a project just using that subset, and at the end of the course you've gotten through everything.

Best,

Nick

On Wed, Sep 1, 2021 at 12:17 AM Steven D'Aprano <steve@pearwood.info> wrote:

On Tue, Aug 31, 2021 at 06:18:15PM -0400, Todd wrote:

> You insist that both approaches should be treated as equally valid. But
> they simply aren't. In the real world, where people are trying to do almost
> anything useful with python, approach 2 is too dangerous to rely on.

In fairness to Nick, he is not talking about the real world. Nick is
talking about the hot-house environment of *education*, where fragile
newbies are generally protected from real world issues.

And let's not exaggerate the issue either by using emotive words like
"dangerous". Outside of numpy arrays and pandas dataframes, I think it
is highly unlikely that anyone in the real world will come across cases
where `x == None` will cause your program to silently do the wrong thing
in a way that can't be solved by telling them "well don't do that then".

In almost all cases, the test we are looking at is used to decide
whether or not to replace a parameter with a mutable default. So in
practical terms, the worst thing that will happen is that the caller
gets the default when they didn't want it.

Numpy arrays and pandas dataframes are two big, important and common
exceptions, but they are exceptional for a different reason: they don't
even return True or False.

Outside of contrived counter-examples, we're not likely to come across
anything trying to mimac None in the real world. But that's not really
why we use `is`, or at least, it's not the only reason. There are a
bunch of reasons, none of which on their own are definitive, but
together settle the issue (in my opinion).

1. Avoid rare bugs caused by weird objects.
2. Slightly faster and more efficient.
3. Expresses the programmer's intent.
4. Common idiom, so the reader doesn't have to think about it.

--
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QQMLKJKGAA5YHE4NJLL25JKMSESPKJAM/
Code of Conduct: http://python.org/psf/codeofconduct/