[Python-Dev] PEP 550 v3 naming

[Nick Coghlan]

On 23 August 2017 at 13:51, Guido van Rossum <guido at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia