[Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

[Ryan Gonzalez]

<opinion>

I have to say I'm not overly thrilled with PEP 572...it's almost odd, 
because if you asked me back when I first joined this list when I was 13, I 
would've no doubt said *YES*. But, since then, I've gone across many 
projects and languages, and fundamentally *I have never felt hurt by the 
lack of assignment in an expression*, and I always regretted every time I 
tried it in C or Crystal. I understand this experience is pretty 
insignificant in comparison to many of the wizards here, but I thought I'd 
still share it as an opener for what I'm about to say.

</opinion>

With this being said, I'd encourage everyone to take a bit of a step back: 
what exactly are people looking for in PEP 572?

I see two main goals:

- Assignment in a conditional structure.
- Assignment in a list comprehension.

Most other use cases would significantly hurt readability and seem pretty rare.

Now let's break down the top one:

- Assignment in an if condition.
- Assignment in a while condition.

So there are roughly three main goals here overall. Now, are there better 
ways to solve these?

(FWIW C solved the while condition one with the C-style for loop, but I'm 
pretty sure few people here would really go for that.)

C++ has recently solved the if condition by allowing declarations inside 
the conditions:

if (auto a = 123; a != 456) {

Many languages have a 'let' expression (using Felix as my example):

if let a = 1, b = 2 in a == b then

Swift has taken a bit of a hybrid between the above two:

if let a = 1, b = 2, a == b {

Now, what's the common theme here? **Declarations should be separate from 
expressions.** We've got languages that range from baggage-filled to 
functional to a bit of all of the above, and none of them have added 
assignment *inside* an expression.

The argument is roughly the same across all boards: you're putting major 
but easy-to-miss side effects in the midst of expressions that *seem* pure.

All this is to say: I'd really encourage everyone here to think a bit more 
about *why* exactly you want this feature, and then think if there's really 
no better way. Any solution that separates declarations would be far more 
readable, (arguably) more Pythonic, and play more nicely with the new-ish 
typing features to boot

I understand reluctance to add a syntax exception like this, but I really 
feel it'd be worth it.

As a side note, I was a strong supporter of comprehension generalizations, 
f-strings, *and* dataclasses. However, this proposal seems a bit ugly and 
excessive for what it's trying to accomplish.

P.S. Yes, the unmatched curly braces were intentional to drive you crazy 
for a few hours. I blame Randall Monroe. You're welcome.

--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/