[Python-Dev] PEP 550 v4

Elvis Pranskevichus elprans at gmail.com
Wed Sep 6 22:00:27 EDT 2017


On Wednesday, September 6, 2017 8:06:36 PM EDT Greg Ewing wrote:
> Nathaniel Smith wrote:
> > The implementation strategy changed radically between v1
> > and v2 because of considerations around generator (not coroutine)
> > semantics. I'm not sure what more it can do to dispel these
> > feelings> 
> > :-).
> 
> I can't say the changes have dispelled any feelings on my part.
> 
> The implementation suggested in the PEP seems very complicated
> and messy. There are garbage collection issues, which it
> proposes using weak references to mitigate. There is also
> apparently some issue with long chains building up and
> having to be periodically collapsed. None of this inspires
> confidence that we have the basic design right.
> 
> My approach wouldn't have any of those problems. The
> implementation would be a lot simpler.

I might have missed something, but your claim doesn't make any sense 
to me.  All you've proposed is to replace the implicit and guaranteed 
push_lc()/pop_lc() around each generator with explicit LC stack 
management.

You *still* need to retain and switch the current stack on every 
generator send() and throw().  Everything else written out in PEP 550 
stays relevant as well.

As for the "long chains building up", your approach is actually much 
worse.  The absense of a guaranteed context fence around generators 
would mean that contextvar context managers will *have* to push LCs 
whether really needed or not.  Consider the following (naive) way of 
computing the N-th Fibonacci number:

def fib(n):
    with decimal.localcontext():
        if n == 0:
            return 0
        elif n == 1:
            return 1
        else:
            return fib(n - 1) + fib(n - 2)

Your proposal can cause the LC stack to grow incessantly even in 
simple cases, and will affect code that doesn't even use generators.

A great deal of effort was put into PEP 550, and the matter discussed 
is far from trivial.  What you see as "complicated and messy" is 
actually the result of us carefully considering the solutions to real-
world problems, and then the implications of those solutions 
(including the worst-case scenarios.)

                               Elvis




More information about the Python-Dev mailing list