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

[Ivan Pozdeev]

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>