PEP 572 and decision-making in Python
lwn.net
lwn.net
I’m sure there are good arguments in favor of assignment expressions, but I think it’s totally wrong to characterize the people who are disagreeing as if they are bikeshedding about mere syntax.
The core debate over PEP 572 is not at all bikeshedding, and the people who vehemently disagree that it is ever possibly useful in Python actually have very substantive, serious points worth extended debate.
I wish it did not devolve into vitriol, sure. But it seems really irritating that the arguments against this PEP are so wildly mischaracterized as if it’s just something trivial. It’s really not trivial. This will make a lot of Python code much, much harder to read and reason about because of side-effectful assignment statements, and it’s really fair to demand a great deal of evidence that the feature provides equal compensating benefits that cannot be achieved with existing straightforward approaches.
I saw an edge case in scope around lambdas in the PEP, but not sure if that's what you're getting at.
Just look at PEP 572 and consider the huge number of examples it gives where it says “valid, but not great style” or “valid but confusing” or “valid but probably never useful.”
It’s bewildering to read, and this is in the highly controlled environment of the very PEP that defines it! Imagine how inscrutable it would be out in the wild, whether through unanticipated confusion from well-meaning authors, or through people trying to be clever and squeeze useless one-liner concision out of it, or nesting its usage and using assignment expression inside positional argument lists all over.
It’s unquestionable that this opens a Pandora’s box of problems for reasoning about code. But it is questionable exactly when or why it ever offers a serious advantage over just breaking assignment statements up into a separate line or an explicitly side-effectful function call (so it can be done inside a lambda, etc).
Just like so many others you simply cannot stand the idea that someone would paint their shed pink and try to argue that this is somehow a fundamental issue, but it’s not. This is Guidos shed, if he wants it pink it will be pink. And you should build your own damn shed if you care so much, instead of lamenting him his choices.
"Python has different operators for bitwise and logical operations which C should copy (already copied with iso646.h except if you try to use them, men will stop shaking hands with you)."
Slightly related: I noticed the other day that VS Code does not highlight and, or, et al. as keywords in a C++ program.
https://www.python.org/dev/peps/pep-0572/#alternative-spelli...
On the other hand additional "as" assignments are not very useful under those statements, so it would not really happen for the most part.
A good compromise discussed was to restrict the "as" assignments to the "if" and "while" statements, and perhaps comprehensions, the only areas there were actual use cases.
The PEP authors didn't like this compromise, even though many new languages are choosing this design. They pushed ahead despite resistance from all angles.
In short, controversial PEPs that reverse twenty-five year old design choices are controversial. Not sure what they were expecting.
https://www.mail-archive.com/python-committers@python.org/ms...
That said, had he given (say) 2 years notice, I still think he should not name a successor nor make those decisions himself since the community would need to learn to govern itself anyway.
This is a sad day, but the sky certainly isn't falling.