osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On 1 July 2018 at 02:37, Tim Peters <tim.peters at gmail.com> wrote:
> [Nick Coghlan]
>
>> ...
>
>> "NAME := EXPR" exists on a different level of complexity, since it
>
>> adds name binding in arbitrary expressions for the sake of minor
>
>> performance improvement in code written by developers that are
>
>> exceptionally averse to the use of vertical screen real estate,
>> ...
>
> Note that PEP 572 doesn't contain a single word about "performance" (neither
> that specific word nor any synonym), and I gave only one thought to it when
> writing Appendix A:  "is this going to slow anything down significantly?".
> The answer was never "yes", which I thought was self-evident, so I never
> mentioned it.  Neither did Chris or Guido.
>
> Best I can recall, nobody has argued for it on the grounds of "performance".
> except in the indirect sense that sometimes it allows a more compact way of
> reusing an expensive subexpression by giving it a name.   Which they already
> do by giving it a name in a separate statement, so the possible improvement
> would be in brevity rather than performance.

The PEP specifically cites this example as motivation:

   group = re.match(data).group(1) if re.match(data) else None

That code's already perfectly straightforward to read and write as a
single line, so the only reason to quibble about it is because it's
slower than the arguably less clear two-line alternative:

   _m = re.match(data)
   group = _m.group(1) if _m else None

Thus the PEP's argument is that it wants to allow the faster version
to remain a one-liner that preserves the overall structure of the
version that repeats the subexpression:

   group = _m.group(1) if _m := re.match(data) else None

That's a performance argument, not a readability one (as if you don't
care about performance, you can just repeat the subexpression).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia