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

[Lukasz Langa]

[Uncle T]
> So, to match your sarcasm, here's mine:  try using a feature for what
> it's good at instead of for what it's bad at ;-)

Yes, this is the fundamental wisdom.  Judging which is which is left as an
exercise to the programmer.

With this, I'm leaving the discussion.  With Guido and you on board for PEP
572, I feel that Chris' streak is indeed about to break.

Some parting hair-splitting follows.


> [Uncle T]
>>> One language feature conspicuous by absence in newbie
>>> confusions was, consistently, assignment expressions.  Read any book
>>> or tutorial for such a language, and you'll find very little space
>>> devoted to them too.
> 
> [Łukasz Langa <lukasz at langa.pl>]
>> Well, you have an entire code style built around this feature called Yoda
>> conditions. You teach people on Day 1 to never ever confuse == with =. Some
>> compilers even warn about this because so many people did it wrong.
> 
[Uncle T]
> Sorry, I couldn't follow that.

You implied that newbies don't have to even know about assignments in
expressions.  I wanted to demonstrate that this isn't really the case because
mistaking `=` for `==` is a relatively common occurence for newbies.  If you
want to argue that it isn't, I'd like to point out that the WordPress code
style *requires* Yoda conditions because it was enough of a hindrance.  ESLint
(a JavaScript linter) also has a warning about assignment in a conditional.


[Uncle T]]
> In languages like C that use easily
> confused operator symbols, sure, people are forever typing "=" when
> they mean "==".  That's nothing to do with whether they _understand_
> what the different operators do, though.

What you're saying is true.  But for it to be true, newbies *have to* learn the
distinction, and the fact that yes, sometimes the programmer indeed meant to
put a single `=` sign in the conditional.  That's why we'll end up with the
Pascal assignment operator.  And that *is* a thing that you will have to
explain to newbies when they encounter it for the first time.  Sadly, googling
for a colon followed by an equal sign isn't trivial if you don't know what
you're looking for.


[Łukasz]
>> Well, you can also use it as a statement. But don't!
> 
[Uncle T]]
> Why not?  _Every_ expression in Python can be used as a statement.
> Nothing forbids it, and that's even (very!) useful at an interactive
> prompt.

Because it suggests different intent, because it's limited, because it's slower
at runtime, and because PEP 572 says so itself.


> At this point I think you must have a lower opinion of Python
> programmers than I have ;-)  If adding even a dozen characters to a
> line makes it exceed a reasonable line-length guide, the code was
> almost certainly too confusingly dense to begin with.

Around 5% of if and elif statements in the standard library don't fit a single
line *as is*.  Sure, that's a low percentage but that's over 1,000 statements.
If you're putting an `if` statement in a method, you are already starting out
with 71 characters left on the line.  Four of those are going to be taken by
"if", a space, and the colon.  Adding a parenthesized assignment expression
takes at least 10% of that available space.

The silver lining for me is that this makes the environment riper for
auto-formatting.


-- Ł