5 ms·

PEP 572 and decision-making in Python

131 points by corbet 8y ago

steve19 8y 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/msg05628.html https://www.mail-archive.com/python-committers@python.org/ms...
- steveklabnik 8y ago
  which is being discussed over here: https://news.ycombinator.com/item?id=17515492 https://news.ycombinator.com/item?id=17515492
- CogitoCogito 8y 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 8y 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 8y ago
  "as" (and other alternatives) are mentioned in the PEP here: https://www.python.org/dev/peps/pep-0572/#alternative-spellings https://www.python.org/dev/peps/pep-0572/#alternative-spelli...
- mixmastamyk 8y 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 8y 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 8y 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 https://en.wikipedia.org/wiki/Law_of_triviality
- mlthoughts2018 8y 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 8y 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.

131 points by corbet 8y 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/msg05628.html https://www.mail-archive.com/python-committers@python.org/ms...

steveklabnik 8y ago
which is being discussed over here: https://news.ycombinator.com/item?id=17515492 https://news.ycombinator.com/item?id=17515492
CogitoCogito 8y 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 8y 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 8y ago
"as" (and other alternatives) are mentioned in the PEP here: https://www.python.org/dev/peps/pep-0572/#alternative-spellings https://www.python.org/dev/peps/pep-0572/#alternative-spelli...
mixmastamyk 8y 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 8y 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 8y 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 https://en.wikipedia.org/wiki/Law_of_triviality

mlthoughts2018 8y 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 8y 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.