PEP 572 and decision-making in Python

https://lwn.net/Articles/757713/

by corbet • 8 years ago

131 12 8 years ago

lwn.net

steve19• 8 years ago

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

https://www.mail-archive.com/python-committers@python.org/ms...

steveklabnik• 8 years ago

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

CogitoCogito• 8 years ago

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.

ehsankia• 8 years ago

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?

philfreo• 8 years ago

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

https://www.python.org/dev/peps/pep-0572/#alternative-spelli...

mixmastamyk• 8 years ago

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.

SloopJon• 8 years ago

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.

liquidise• 8 years ago

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

mlthoughts20182• 8 years ago

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.

tedmiston• 8 years ago

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.

talltimtom• 8 years ago

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.

PEP 572 and decision-making in Python

Related Stories