On Fri, Apr 27, 2018 at 8:19 PM, Tim Peters <tim.peters@gmail.com> wrote:

[Lukasz]
>> > And that *is* a thing that you will have to explain to newbies when
>> > they encounter it for the first time.

Which they will presumably do either in class or by reading code. No sensible instructor or course author is going to bring name-binding expressions up until standard assignment has been thoroughly assimilated. In my own teaching experience I observed that those used to static languages took a little time to adapt to the indirection of Python's names, but not long.

[...]

Sure. What I wrote was shorthand for what's already been covered at
length many times: what a binding expression does is "easy to
explain" GIVEN THAT someone ALREADY UNDERSTANDS how binding a name
works. The latter in fact seems difficult for a significant number of
people to learn, but it's utterly unavoidable that they learn it if
they're ever to write non-trivial Python programs. That's been true
since Python's first release.

I was half-expecting someone to pop up and suggest only functional programming as a means to avoid having to teach assignment ...

Binding expressions would be introduced much later in any sane course.
At THAT point, for students who haven't already dropped out, the
semantics are darned-near trivial to explain: it binds the name to
the object the expression evaluates to (all of which they _already_
understand by this point), and the value of the binding expression is
that object (the only new bit).

Unlike as for most other operators, you don't even have to weasel-word
it to account for that a magical dunder method may change what ":="
does. As for the "is" operator, the meaning is baked into the
language and can't be altered in the slightest.

> So having one more way to do assignment WILL make it harder to
> teach, not because it's that hard, but because it's one more thing to learn.

But surely that depends on HOW MUCH of the language you aim to teach. Over the years Python has become a much more complex language, but it has a fairly easily-identified subset that can act as a basis for building useful programs. Some instructors avoided teaching comprehensions, but a sensible course would try to ensure that students could understand the code they were most likely to encounter "in the wild."

[
...]

> You now, I think instructors like me are partly responsible. "is" is rarely
> useful outside of comparing to singletons. Yet I use it early in instruction
> to do checks on name binding and show things with mutablilty, etc.... which
> has the unfortunate side effect of making it seem like a more common
> operator than it is.
>

I'd expand that to say that identity comparison is most useful for types whose instances are all unique. For other types there's the unfortunate impedance mismatch between identity and equality (which is user-definable anyway).

> I've even had students write code like:
>
> if x is 3:
>
> and thanks to interning, it appears to work!

No, thanks to interning it DOES work. For interned values.

But instructors have to touch on implementation artefacts at times, and I used to find it instructive to write the same code with two different integer constants and ask why they gave different results. It certainly helped people to master the semantics of assignment (as did the phrase "Python never copies data on assignment").

Yup, that's the real problem with "is": its semantics are dead
simple, but "but under exactly what conditions are `x` and `y` bound
to the same object?" is intractable. It seems to take a long time to
get across the point, that the question itself is misguided. A full
answer requires delving into transient implementation details, which
is counterproductive because they _are_ accidents of the
implementation du jour. What questioners need to be nudged into
asking instead is for examples of when using "is" is thoroughly sane.

I'd argue that without some knowledge of the potential pitfalls students can't be expected to learn how to make that distinction.

regards

Steve