[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Tim Peters]

[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 at 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.