[Python-Dev] PEP 572: Assignment Expressions

Chris Angelico rosuav at gmail.com
Thu Apr 26 14:00:35 EDT 2018


On Fri, Apr 27, 2018 at 3:33 AM, Sven R. Kunze <srkunze at mail.de> wrote:
> On 25.04.2018 01:19, Steven D'Aprano wrote:
>>
>> Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that
>> sometimes g is better. [...]
>
>
> We were talking about the real-world code snippet of Tim (as a justification
> of := ) and alternative rewritings of it without resorting to new syntax.
> Not about "sometimes", or in some toy examples, or code without unknown
> life-time and intention (interactive, library, etc).

You're asking for some massive changes in semantics, though. If you
want to discuss that, it's nothing at all to do with PEP 572, and is a
completely new proposal.

>> You might know that, but how does somebody reading the code know
>> which functions are pure and which are not? How does the compiler know?
>
>
> There are invisible optimizations in CPython already.
> And for the most obvious examples, humans don't need to know. It's like
> wondering if constant folding really works.
> It's the same with all optimizations: if it works, it's fine. If it cannot
> be made working, the original code still works and you can optimize by hand
> anyway.
> The two obvious ways: the compiler might have a predefined list of pure
> functions OR the code tells him with an annotation of any sort.
> Both ways work, the latter somehow feels cleaner.

An annotation? You mean like functools.lru_cache? That's technically
nothing to do with pure functions, but it's about as much as you're
likely to get. The function still has to be called, and the result has
to be cached somewhere. Ultimately, "pure function optimization" is
just another form of cache.

Please, take this to python-ideas, or even better, to python-list.
It's not a counter-argument to PEP 572.

ChrisA


More information about the Python-Dev mailing list