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