[Python-Dev] Examples for PEP 572

[Nathaniel Smith]

On Tue, Jul 3, 2018 at 11:14 PM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> 04.07.18 04:26, Tim Peters пише:
>>
>> I really don't know what Guido likes best about this, but for me it's the
>> large number of objectively small wins in `if` and `while` contexts.   They
>> add up.  That conclusion surprised me.  That there are occasionally bigger
>> wins to be had is pure gravy.
>
>
> Could you please show me several examples in real code? I have not seen any
> win yet.

The new version of the PEP has several real examples -- there are some
"sanitized" ones in this section inspired by Guido's trawling through
Dropbox code:

https://www.python.org/dev/peps/pep-0572/#the-importance-of-real-code

And Tim's appendix has several more, most from his code plus one that
Kirill Balunov found in the stdlib:

https://www.python.org/dev/peps/pep-0572/#appendix-a-tim-peters-s-findings

This is much nicer than the old PEP! Unfortunately I don't find any of
these examples convincing myself :-(.

Most of them (the Dropbox ones and the first few in Tim's appendix)
look like great arguments for pattern matching syntax, which is
basically an elegant way of writing chained 'if's and capturing values
along the way. And at PyCon Guido was saying he hoped we'd also get a
good proposal for pattern matching syntax for 3.8, so for these cases
:= will hopefully be obsolete before it even ships...

The last two in Tim's appendix are the "best" examples, in the sense
that they really do depend on the full power of :=. Unfortunately (as
Tim acknowledges) the code is fairly incomprehensible to non-Tims
regardless of which syntax is used, so to me they aren't really any
more convincing than foo/bar examples. But, if I found myself forced
to maintain this code, my first step in deciphering it would be to
rewrite it to remove the :='s, just to simplify the control flow, so
that I could focus on understanding each statement in isolation.

The PEP spends a ton of time talking about comprehensions, but still
has zero real examples of comprehensions that would be improved by :=.

The only cases that seem potentially valuable to me are the ones that
are literally the form 'if <name> := <expr>` and 'while <name> :=
<expr>'. (I suspect these are the only cases that I would allow in
code that I maintain.) The PEP does briefly discuss the alternative
proposal of restricting to just these two cases, but rejects it
because it would rule out code like 'if (<name> := <expr>)
<comparison> <expr>'. But those are exactly the cases that I want to
rule out, so that seems like a plus to me :-).

The 'if <expr> as <name>' syntax would be a simple way to encode
exactly these simple non-harmful cases. The PEP rejects it on the
grounds that 'as' is already used in a different way by 'except' and
'with'. But... 'as' is *also* used in the *same* way by 'import', so
the argument feels disengenuous. Yeah, there'd be an inconsistency,
but that inconsistency already exists, and adding 'if ... as' and
'while ... as' wouldn't create any *new* inconsistencies.

Guido has asked for PRs to the PEP to flesh out the rejected
alternatives and replies-to-common-complaints sections, and I'd be
happy to write up something for that, except that despite all the
electrons that have been spilled I actually do not know what the PEP
authors response would be to the issues that bother me :-(.

-n

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