Hacker News new | comments | show | ask | jobs | submit login
PEP 572 and decision-making in Python (lwn.net)
131 points by corbet 5 days ago | hide | past | web | favorite | 12 comments

My armchair analysis of this today has exposed, to me, the serious risks of bikeshedding[0] taken to an extreme. So much contentious debate about 1-3 character syntax preferences. The consequences from the debate being deeply more impactful than any of the proposed options in the first place.

0: https://en.wikipedia.org/wiki/Law_of_triviality

I don’t have any horse in the PEP 572 race, but it is bang obvious that the debate has absolutely nothing to do with mere syntax preferences (a minor part at best). Rather it is about whether permitting expressions to have assignment as a side-effect is ever a good idea or a useful feature. I think people make very solid arguments that in Python, at least, it really is not ever a useful idea, and the downside about reasoning about side-effect assignment is a serious consideration, meanwhile the examples that supposedly motivate the PEP, like re.match or iter.chunk, are borderline comically bad examples because they make it seem like “one-liner-ness” is the priority for such a drastic, side-effect-based language feature.

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.

The core is bikesheding and your post is bikesheding too. You start out saying you don’t have a horse in the race yet you still want to debate.

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.

By side effects of the assignment, what specific side effects are you referring to exactly? Or just the fact that assignment is happening inside of an expression?

I saw an edge case in scope around lambdas in the PEP, but not sure if that's what you're getting at.

I mean that the phenomenon of assignment happens as a side-effect of an expression.

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).

This cracked me up:

"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.

They have a list of proposals for syntax, but "as" keyword isn't there. In the last thread I saw, people claimed that it would be confusing in the with-statement, but I have a hard time seeing why. In a with statement, the context manager in my eyes is a property of the with-statement, not the as-statement. You're basically doing `with fp = open():`. Does anyone have a good example of why "as" was a bad candidate?

The behavior is built into the "with" statement. It does not do a direct assignment, but assigns to the result of the context manager call. So having two ways to use "as" in the same statement, with different rules, and confusion of which is which is a mess. Except and import have the issue also with different rules.

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.

"as" (and other alternatives) are mentioned in the PEP here:


And Van Rossum has just quit without naming a successor or giving any guidance on how python should be governed!


I think you're probably blowing it a little out of proportion. I'm sure he'll give guidance and advice to people (who ask for it). He said he would he would still be involved as a core dev after all.

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.

which is being discussed over here: https://news.ycombinator.com/item?id=17515492

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact