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

Nick Coghlan ncoghlan at gmail.com
Sat Jun 30 22:50:23 EDT 2018

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

More information about the Python-Dev mailing list