[Python-Dev] Don't assign to a variable used later in the expression (original) (raw)

Ivan Pozdeev vano at mail.mipt.ru
Wed Jul 4 19:10:46 EDT 2018

On 04.07.2018 10:10, Nathaniel Smith wrote:

On Tue, Jul 3, 2018 at 11:07 PM, Serhiy Storchaka<storchaka at gmail.com> wrote:

04.07.18 00:51, Chris Angelico пише:

On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka<storchaka at gmail.com> wrote:

I believe most Python users are not professional programmers -- they are sysadmins, scientists, hobbyists and kids -- [citation needed] I don't understand what citation do you need.

In particularly mutating and non-mutating operations are separated. The assignment expression breaks this. [citation needed] In Python the assignment (including the augmented assignment) is a statement, del is a statement, function and class declarations are statements, import is a statement. Mutating methods like list.sort() and dict.update() return None to discourage using them in expressions. This a common knowledge, I don't know who's citation you need. Right, Python has a very strong convention that each line should have at most one side-effect, and that if it does have a side-effect it should be at the outermost level. I think the most striking evidence for this is that during the discussion of PEP 572 we discovered that literally none of us – including Guido – even know what the order-of-evaluation is inside expressions. In fact PEP 572 now has a whole section talking about the oddities that have turned up here so far, and how to fix them. Which just goes to show that even its proponents don't actually think that anyone uses side-effects inside expressions, because if they did, then they'd consider these changes to be compatibility-breaking changes. Of course the whole point of PEP 572 is to encourage people to embed side-effects inside expressions, so I hope they've caught all the weird cases, because even if we can still change them now we won't be able to after PEP 572 is implemented.

I may have a fix to this:

Do not recommend assigning to the variable that is used later in the expression.

And to facilitate that, do not make any strong guarantees about evaluation order -- making any such attempt a gamble.

I immediately saw those "total := total + item" as odd but couldn't quite point out why. Now I see: it ignores the whole augmented assignment machinery thing, which will make people demand that next. Making this a discouraged case will diminish valid use cases and lower the need for that.

Some people make fun of Python's expression/statement dichotomy, because hey don't you know that everything can be an expression, functional languages are awesome hurhur, but I think Python's approach is actually very elegant. Python is unapologetically an imperative language, but even we dirty imperative programmers can agree with the functional fanatics that reasoning about side-effects and sequencing is hard. One-side-effect-per-line is a very elegant way to keep sequencing visible on the page and as easy to reason about as possible.

Or as Dijkstra put it: "our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible." It's very disheartening that not only is PEP 572 apparently going to be accepted, but as far as I can tell neither the text nor its proponents have even addressed this basic issue. -n

-- Regards, Ivan

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180705/6a092141/attachment.html>

More information about the Python-Dev mailing list