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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
