On Wed, Aug 16, 2017 at 11:03 AM, Nick Coghlan <[email protected]> wrote: > On 17 August 2017 at 00:25, Stefan Krah <[email protected]> wrote: >> Perhaps it would be possible to name the data structures by their >> functionality. >> E.g. if ExecutionContext is a stack, use ExecutionStack? >> >> Or if the dynamic scope angle should be highlighted, perhaps ExecutionScope >> or even DynamicScope. >> >> This sounds like bikeshedding, but I find it difficult to have >> ExecutionContext, >> ContextItem, LocalContext in addition to the actual decimal.localcontext() >> and PyDecContext. >> >> For example, should PyDecContext inherit from ContextItem? I don't fully >> understand. :-/ > > Agreed, I don't think we have the terminology quite right yet. > > For "ContextItem" for example, we may actually be better off calling > it "ContextKey", and have the methods be "ck.get_value()" and > "ck.set_value()". That would get us closer to the POSIX TSS > terminology, and emphasises that the objects themselves are best seen > as opaque references to a key that lets you get and set the > corresponding value in the active execution context.
With the confusion of what "empty ExecutionContext" and "ContextItem is set to None by default", I tend to agree that "ContextKey" might be a better name. A default for "ContextKey" means something that will be returned if the lookup failed, plain and simple. > > I do think we should stick with "context" rather than bringing dynamic > scopes into the mix - while dynamic scoping *is* an accurate term for > what we're doing at a computer science level, Python itself tends to > reserve the term scoping for the way the compiler resolves names, > which we're deliberately *not* touching here. +1, I feel the same about this. > > Avoiding a naming collision with decimal.localcontext() would also be > desirable. The ContextItem (or ContextKey) that decimal will be using will be an implementation detail, and it must not be exposed to the public API of the module. > > Yury, what do you think about moving the ExecutionContext name to what > the PEP currently calls LocalContext, and renaming the current > ExecutionContext type to ExecutionContextChain? While I think that the naming issue is important, the API that will be used most of the time is ContextItem. That's the name in the spotlight. > > The latter name then hints at the collections.ChainMap style behaviour > of ck.get_value() lookups, without making any particular claims about > what the internal implementation data structures actually are. > > The run methods could then be sys.run_with_context_chain() (to ignore > the current context entirely and use a completely separate context > chain) and sys.run_with_active_context() (to append a single execution > context onto the end of the current context chain) sys.run_with_context_chain and sys.run_with_active_context sound *really* confusing to me. Maybe it's because I spent too much time thinking about the current PEP 550 naming. To be honest, I really like Execution Context and Local Context names. I'm curious if other people are confused with them. Yury _______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
