On 14 October 2017 at 17:50, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 14 October 2017 at 21:56, Paul Moore <p.f.moore@gmail.com> wrote:
TL;DR of below: PEP 550 currently gives you what you're after, so your perspective counts as a preference for "please don't eagerly capture the creation time context in generators or coroutines".
Thank you. That satisfies my concerns pretty well.
The suggestion has been made that we should instead be capturing the active context when "url_get(url)" is called, and implicitly switching back to that at the point where await is called. It doesn't seem like a good idea to me, as it breaks the "top to bottom" mental model of code execution (since the "await cr" expression would briefly switch the context back to the one that was in effect on the "cr = url_get(url)" line without even a nested suite to indicate that we may be adjusting the order of code execution).
OK. Then I think that's a bad idea - and anyone proposing it probably needs to explain much more clearly why it might be a good idea to jump around in the timeline like that.
If you capture the context eagerly, then there are fewer opportunities to get materially different values from "data = list(iterable)" and "data = iter(context_capturing_iterable)".
While that's a valid intent for folks to want to be able to express, I personally think it would be more clearly requested via an expression like "data = iter_in_context(iterable)" rather than having it be implicit in the way generators work (especially since having eager context capture be generator-only behaviour would create an odd discrepancy between generators and other iterators like those in itertools).
OK. I understand the point here - but I'm not sure I see the practical use case for iter_in_context. When would something like that be used? Paul