[Python-Dev] PEP 572: Assignment Expressions (original) (raw)

Yury Selivanov yselivanov.ml at gmail.com
Mon Apr 30 13:34:49 EDT 2018

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 dothings(firemissiles=False, plantflowers=False): ... >> > dothings(plantflowers:=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

More information about the Python-Dev mailing list