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-synchronizationcontext/ 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 _______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
