
PEP 572 and decision-making in Python - corbet
https://lwn.net/Articles/757713/
======
liquidise
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
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
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.

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

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

------
ehsankia
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?

~~~
mixmastamyk
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.

------
steve19
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...](https://www.mail-archive.com/python-
committers@python.org/msg05628.html)

~~~
CogitoCogito
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.

