On 23 August 2017 at 13:51, Guido van Rossum <gu...@python.org> wrote: > Regarding DynamicAnything, I certainly saw it and didn't like it -- the only > place where I've ever seen dynamic scoping was in Emacs Lisp, and I believe > was first shown to me as anti-pattern thirty years ago.
As the original proponent of a Dynamic* naming scheme, I'll note that I eventually decided I didn't like it for the same reason I already didn't like naming schemes using either the word "local" or the word "frame": they all suggest a coupling to the synchronous call stack that deliberately isn't part of the proposal. That is (at least for me): - "local" suggests the implicit context will change when locals() changes - "frame" suggests the implicit context will change when the running frame changes - "dynamic" suggest dynamic scoping, which again suggests the implicit context will change on every function call None of those associations are true, since the essential point of the proposal is to *share* implicit state between frames of execution. The tricky part is defining exactly which frames should and shouldn't share their implicit context - threading.locals() is our current best attempt, and the PEP is mainly driven by the problems introduced by relying solely on that in programs that implement concurrent execution of Python code independently of the underlying operating system threads. My concern with "logical" context is different, which is that as a term it feels too *broad* to me: I'd expect the lexical context (nonlocals, module globals), the explicit context (function parameters), and the runtime context (process globals, threading.locals()) to also be considered part of the overall logical context. It's also a very computer-sciencey term of art - if you ask an arbitrary English speaker "What does 'logical' mean?", they're very *un*likely to give you an answer that has anything to do with logical threads of control in computer programs. My latest suggestion (ImplicitContext) has some of the same issues as "logical context" (since the runtime context is also implicit), but seems more defensible on the grounds of it aiming to be a more robust way of accessing and manipulating implicit state in concurrent programs, rather than it being the only kind of implicit state that exists in an application. As an English word, the sense of "capable of being understood from something else though unexpressed" (the first definition that Merriam-Webster give) also has the benefit of describing *exactly* what the PEP is aiming to achieve. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com