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

Tim Peters tim.peters at gmail.com
Fri Jun 29 23:58:45 EDT 2018

[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 = callafunc(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>

More information about the Python-Dev mailing list