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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4