[Lukasz]
And that *is* a thing that you will have to explain to newbies when they encounter it for the first time.
[Tim]
Sure. That doesn't frighten me, though. It's easy to explain what it does - although it may be hard to explain when it's _desirable_ to use it.
[Chris Barker <chris.barker@noaa.gov>]
I'm with Raymond here -- though I'm not sure "newbies" is quite right -- I've found that newbies fall into two camps: folks to whom programming comes naturally, and those that it doesn't (OK, it's a distribution, but a bimodal one). And folks that are struggling with programming can struggle even with simple assignment (name binding), particularly when you add even function local scope.
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.
On a scale of 1 to a million, try to quantify how much harder ;-) As above, I can't see it getting beyond a single digit, GIVEN THAT a student has already masteredf the far more complex assignment _statement_ (binding expressions are limited to the single simplest case of the many things an assignment statement can do). "And it returns the object" is a yawn. But, as I already granted, it may be truly hard to explain when it's a desirable thing to use. That takes experience and "good judgment", which - according to me - can be learned but can't really be taught.
But the fact is that as Python has evolved (particularly with the jump to py3) it has become less and less of a "scripting" language, and more of a "systems" language. And also harder to learn. Anyone remember CP4E? Python is not as good choice as a "newbie" language as it once was.
I agree - although I expect sticking to a subset of Python could make life easier for beginners. For example, would anyone in their right mind even mention async gimmicks when teaching beginners? Against that, though, one of the most unintentionally funny tech things I ever read was Bjarne Stroustrup writing about why C++ is an excellent choice for beginners. But he does have a point: if you throw away the bulk of everything C++ added, there's an easily usable little language exceedingly well hidden under it all ;-)
Adding := will move it a little bit more along the complexity path -- not much, and that's where Python has gone anyway, so as Tim said, no one's going to suffer either way this decision goes.
Yet there will be much wailing and gnashing of teeth anyway ;-) ...
To judge from Stackoverflow volume, the single most misunderstood of all Python operators - by far - is "is" -
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.