[Python-Dev] Examples for PEP 572

[Nathaniel Smith]

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.

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

-- 
Nathaniel J. Smith -- https://vorpus.org