[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20 (original) (raw)

Raymond Hettinger raymond.hettinger at gmail.com
Wed Apr 25 23:34:44 EDT 2018

On Apr 25, 2018, at 8:11 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:

FWIW I started my thread for allowing '=' in expressions to make sure that we fully explore that path. I don't like ':=' and I thought that using '=' can make the idea more appealing to myself and others. It didn't, sorry if it caused any distraction. Although adding a new ':=' operator isn't my main concern. I think it's a fact that PEP 572 makes Python more complex. Teaching/learning Python will inevitably become harder, simply because there's one more concept to learn. Just yesterday this snippet was used on python-dev to show how great the new syntax is: myfunc(arg, buffer=(buf := [None]*getsize()), size=len(buf)) To my eye this is an anti-pattern. One line of code was saved, but the other line becomes less readable. The fact that 'buf' can be used after that line means that it will be harder for a reader to trace the origin of the variable, as a top-level "buf = " statement would be more visible. The PEP lists this example as an improvement: [(x, y, x/y) for x in inputdata if (y := f(x)) > 0] I'm an experienced Python developer and I can't read/understand this expression after one read. I have to read it 2-3 times before I trace where 'y' is set and how it's used. Yes, an expanded form would be ~4 lines long, but it would be simple to read and therefore review, maintain, and update. Assignment expressions seem to optimize the writing code part, while making reading part of the job harder for some of us. I write a lot of Python, but I read more code than I write. If the PEP gets accepted I'll use the new syntax sparingly, sure. My main concern, though, is that this PEP will likely make my job as a code maintainer harder in the end, not easier. I hope I explained my -1 on the PEP without sounding emotional.

FWIW, I concur with all of Yuri's thoughtful comments.

After re-reading all the proposed code samples, I believe that adopting the PEP will make the language harder to teach to people who are not already software engineers. To my eyes, the examples give ample opportunity for being misunderstood and will create a need to puzzle-out the intended semantics.

On the plus side, the proposal does address the occasional minor irritant of writing an assignment on a separate line. On the minus side, the visual texture of the new code is less appealing. The proposal also messes with my mental model for the distinction between expressions and statements.

It probably doesn't matter at this point (minds already seem to be made up), but put me down for -1. This is a proposal we can all easily live without.

Raymond

More information about the Python-Dev mailing list