[Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Tim Peters]

[Tim]
>> Regardless of how assignment expressions work in listcomps and genexps,
>> this example (which uses neither) _will_ rebind the containing block's
`x`:

> >>

> >> [x := 1]

>
[Chris Barker]
> This reinforces my point that it’s not just about comprehensions,

I agree, it's not at all - and I'm amazed at the over-the-top passion that
minor issues of scope in comprehensions have ... inspired.  It's the tip of
the tail of the dog.

> but rather that the local namespace can be altered anywhere
> an expression is used  — which is everywhere.

Yes, everywhere.  But what of it?  Have you read the PEP?  The examples are
all simple and straightforward and "local".  My example above was wholly
contrived to make a specific point, and I expect we'll _never_ see that
line in real code.

>

> That trivial example is unsurprising, but as soon as your
> line of code gets a bit longer, it could be far more hidden.

It's not possible to prevent people from writing horrible code, and I'm
hard pressed to think of _any_ programming feature that can't be so
abused.  From
ridiculouslyLongVariableNamesWhoseVerbostiySeemsToBeAGoalInItself. massive
overuse of globals, insanely deep nesting, horridly redundant
parenthesization, functions with 20 undocumented arguments, creating
Byzantine class structures spread over a directory full of modules to
implement a concept that _could_ have been done faster and better with a
list, ...

So on a scale of 1 ("wake me up when it's over") to 100 ("OMG!  It's the
end of the world!!!"), "but it can be horridly abused" rates about a 2 on
my weighting scale.  Do we really think so little of our fellow
Pythoneers?  Key point:  absolutely nobody has expressed a fear that they
_themself_ will abuse assignment expressions.  It's always some seemingly
existential dread that someone else will ;-)


> I’m not saying it’s not worth it, but it a more significant

> > complication than simply adding a new feature like augmented

> > assignment or terniary expressions, where the effect is seen only

> > where it is used.

Which is good to keep in mind when using a feature like this.  Python is an
imperative language, and side effects are rampant.  Controlling them is
important.


> A key problem with thinking about this is that we can scan existing
> code to find places where this would improve the code, and decide if
> those use-cases would cause confusion.

I went through that exercise for the PEP's Appendix A.  I assume you
haven't read it.  I found many places where assignment expressions would
make for a small improvement, and got surprised by concluding it was really
the multitude of tiny, extremely-local improvements that "added up" to the
real win overall, not the much rarer cases where assignment expressions
really shine (such as in collapsing chains of semantically misleading
ever-increasing indentation in long
assign/f/else/assign/if/else/assign/if/else ...structures).  I also gave
examples of places where, despite being "small and local" changes, using
assignment expressions appeared to be a _bad_ idea.


> But we really can’t anticipate all the places where it might get used

> > perhaps inappropriately) that would cause confusion. We can hope that
> people won’t tend to do that, but who knows?

Having spent considerable time on it myself (see just above), I do not
assume that other Pythonistas are incapable of reaching sane conclusions
too ;-)


> Example: in a function argument:

> >

> > result = call_a_func(arg1, arg2, kwarg1=x, kwarg2=x:=2*y)

The PEP already calls that one a SyntaxError.  I can't imagine why a sane
programmer would want to do that, but if they really must the PEP _will_
allow it if they parenthesize the assignment expression in this context (so
"kwarg2=(x:=2*y)" instead.


> Sure, there are always ways to write bad code, and most people

> > wouldn’t do that, but someone, somewhere, that thinks shorter code is

> > better code might well do it. Or something like it.

Someone will!  No doubt about it.  But what of it?  If someone is
programming for their own amusement, why should I care?  If they're working
with a group, bad practice should be discouraged by the group's coding
standards and enforced by the group's code review process.  For this
feature, and all others.

"Consenting adults" is a key Python principle too.  And I believe in it,
despite that I wrote tabnanny.py ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180629/71f7015e/attachment-0001.html>