<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/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
