[Python-Dev] PEP 572: Assignment Expressions

[Yury Selivanov]

On Mon, Apr 30, 2018 at 1:03 PM Chris Angelico <rosuav at gmail.com> wrote:
> > That's a weird argument, Chris :-)
> >
> > If `f(x)` has no meaningful name, then *what* is the result of the
> > comprehension?  Perhaps some meaningless data? ;)

> f(x) might have side effects. Can you give a meaningful name to the
> trivial helper function?

I don't understand your question. How is `f(x)` having side effects or not
having them is relevant to the discussion? Does ':=' work only with pure
functions?

> Not every trivial helper can actually have a
> name that saves people from having to read the body of the function.

I don't understand this argument either, sorry.

> >> We've been over this argument plenty, and I'm not going to rehash it.
> >
> > Hand-waving the question the way you do simply alienates more core devs
to
> > the PEP.  And PEP 572 hand-waves a lot of questions and concerns.
Asking
> > people to dig for answers in 700+ emails about the PEP is a bit too
much,
> > don't you agree?
> >
> > I think it's PEP's author responsibility to address questions right in
> > their PEP.

> If I answer every question, I make that number into 800+, then 900+,
> then 1000+. If I don't, I'm alienating everyone by being dismissive.
> If every question is answered in the PEP, the document itself becomes
> so long that nobody reads it. Damned if I do, damned if I don't. Got
> any alternative suggestions?

IMO, big part of why that we have 100s of emails is because people are very
concerned with readability.  The PEP just hand-waives the question
entirely, instead of listing good and realistic examples of code, as well
as listing bad examples.  So that, you know, people could compare them and
understand *both* pros and cons.

Instead we have a few very questionable examples in the PEP that most
people don't like at all. Moreover, half of the PEP is devoted to fixing
comprehensions scoping, which is almost an orthogonal problem to adding a
new syntax.

So my suggestion remains to continue working on the PEP, improving it and
making it more comprehensive. You're free to ignore this advice, but don't
be surprised that you see new emails about what ':=' does to code
readability (with the same arguments).  PEP 572 proponents answering to
every email with the same dismissive template doesn't help either.

> >> > def do_things(fire_missiles=False, plant_flowers=False): ...
> >> > do_things(plant_flowers:=True) # whoops!
> >
> >> If you want your API to be keyword-only, make it keyword-only. If you
> >
> > Another hand-waving.  Should we deprecate passing arguments by name if
> > their corresponding parameters are not keyword-only?
> >
> > Mark shows another potential confusion between '=' and ':=' that people
> > will have, and it's an interesting one.

> A very rare one compared to the confusions that we already have with
> '=' and '=='. And this is another argument that we've been over,
> multiple times.

How do you know if it's rare or not?  '=' is used to assign, ':=' is used
to assign, '==' is used to compare.  I can easily imagine people being
confused why '=' works for setting an argument, and why ':=' doesn't.
Let's agree to disagree on this one :)

> > Strange. I see people who struggle to format their code properly or use
the
> > language properly *every day* ;)

> And do they blame the language for having a comparison operator that
> is so easy to type? Or do they fix their bugs and move on? Again,
> language syntax is not the solution to bugs.

I'm not sure how to correlate what I was saying with your reply, sorry.

Anyways, Chris, I think that the PEP hand-waves a lot of questions and
doesn't have a comprehensive analysis of how the PEP will affect syntax and
readability. It's up to you to consider taking my advice or not. I'll try
to (again) restrain myself posting about this topic.

Y