On Thu, Aug 24, 2017 at 10:04:58AM -0400, Barry Warsaw wrote:
Jim J. Jewett wrote:
I know I'm not the only one who is confused by at least some of the alternative terminology choices. I suspect I'm not the only one who sometimes missed part of the argument because I was distracted figuring out what the objects were, and forgot to verify what was being done and why. I also suspect that it could be much simpler to follow if the API were designed in the abstract, with the implementation left for later.
You're definitely not alone! I think I get the gist of the proposal, and its motivation, but I'm definitely confused by the terminology. As I stated elsewhere, the word "context" has a well-established meaning in Python, with context managers, their protocols, and contextlib. When talking with another Pythonista three years from now, I don't want to have to resolve which context they're talking about based on context. ;)
I'm not happy about "context" either. I'd prefer something more pedantic, like: TaskLocalStorage, TaskLocalStorageStack, even when generators aren't tasks. At least that's what people are used to from ThreadLocalStorage. The .NET termiology is explained here: https://blogs.msdn.microsoft.com/pfxteam/2012/06/15/executioncontext-vs-sync... But that is more of an OO approach --- there are more "subclasses" of ExecutionContexts like SecurityContext, HostExecutionContext, CallContext and there's colorful terminology like "flowing the Execution Context". Stefan Krah