>> > And that *is* a thing that you will have to explain to newbies when
>> > they encounter it for the first time.
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.
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.
> 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've even had students write code like:
> if x is 3:
> and thanks to interning, it appears to work!
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.