Re: [Python-Dev] PEP 550 v3

2017-08-20 Thread Ethan Furman 

On 08/19/2017 10:41 PM, Nick Coghlan wrote:

On 20 August 2017 at 10:21, Guido van Rossum wrote:



The way we came to "logical context" was via "logical thread (of control)",
which is distinct from OS thread. But I think we might need to search for
another term...


Right. Framing it in pragmatic terms, the two entities that we're
attempting to name are:

1. The mutable storage that ContextKey.set() writes to
2. The dynamic context that ContextKey.get() queries

Right now, we're using ExecutionContext for the latter, and
LogicalContext for the former, and I can definitely see Antoine's
point that those names don't inherently convey any information about
which is which.


> [snip]


 # Replacing ExecutionContext in the current PEP
 DynamicQueryContext
 sys.get_dynamic_query_context()
 sys.new_dynamic_query_context()
 sys.run_with_dynamic_query_context()
 # Suggests immutability -> good!
 # Suggests connection to ck.get() -> good!

 # Replacing LogicalContext in the current PEP
 ExecutionContext
 sys.new_execution_context()
 sys.run_with_execution_context()
 __execution_context__ attribute on generators (et al)
 # Neutral on mutability/immutability
 # Neutral on ck.set()/ck.get()



[snippety snip]



 # Replacing ExecutionContext in the current PEP
 DynamicQueryContext
 sys.get_query_context()
 sys.new_query_context()
 sys.run_with_query_context()
 # Suggests immutability -> good!
 # Suggests connection to ck.get() -> good!

 # Replacing LogicalContext in the current PEP
 DynamicWriteContext
 sys.new_write_context()
 sys.run_with_write_context()
 __write_context__ attribute on generators (et al)
 # Suggests mutability -> good!
 # Suggests connection to ck.set() -> good!


This is just getting more confusing for me.

Going back to Yury's original names for now...

Relating this naming problem back to globals() and locals(), the correlation works okay for locals/LocalContext, but 
breaks down at the globals() level because globals() is a specific set of variables -- namely, module-level assignments, 
while ExecutionContext would be the equivalent of globals, nonlocals, and locals all together.


A more accurate name for ExecutionContext might be ParentContext, but that would imply that the LocalContext is not 
included, and it is (if I finally understand what's going on, of course).


So I like ExecutionContext for the stack of WhateverWeCallTheOtherContext contexts.  But what do we call it?  Again, if 
I understand what's going on, a normal, threadless, non-async, generator-bereft, plain vanilla Python program is going 
to have only one LocalContext no matter how many nor how deep the function call chain goes -- so in that sense Local 
isn't really the best word, but Context all by itself is /really/ unhelpful, and Local does imply "the most current 
Context Layer".


Of all the names proposed so far, I think LocalContext is the best reminder of the thing that CK.key writes to.  For the 
piled layers of LocalContexts that CK.key.get searches through, either ExecutionContext or perhaps ContextEnvironment or 
even ContextStack works for me (the stack portion not being an implementation detail, but a promise of how it 
effectively works).


--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 550 v3

2017-08-20 Thread Antoine Pitrou 
On Sat, 19 Aug 2017 17:21:03 -0700
Guido van Rossum  wrote:
> The way we came to "logical context" was via "logical thread (of control)",
> which is distinct from OS thread. But I think we might need to search for
> another term...

Perhaps "task context"?  A "task" might be a logical thread, OS thread,
or anything else that deserves a distinct set of implicit parameters.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 550 v3

2017-08-20 Thread francismb 
Hi Yury,

On 08/18/2017 10:33 PM, Yury Selivanov wrote:
> * ``.get()`` method: return the current EC value for the context key.
>   Context keys return ``None`` when the key is missing, so the method
>   never fails.
Is the difference between `Key not found` and `value is None` important
here?

Thanks,
--francis
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 2.7.14 schedule

2017-08-20 Thread Benjamin Peterson 
Hi all,
I've set the 2.7.14 release schedule. There will be a release candidate
on August 26 with a planned final for September 16.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 550 v3

2017-08-20 Thread Brett Cannon 
On Sun, Aug 20, 2017, 03:08 Antoine Pitrou  wrote:

> On Sat, 19 Aug 2017 17:21:03 -0700
> Guido van Rossum  wrote:
> > The way we came to "logical context" was via "logical thread (of
> control)",
> > which is distinct from OS thread. But I think we might need to search for
> > another term...
>
> Perhaps "task context"?  A "task" might be a logical thread, OS thread,
> or anything else that deserves a distinct set of implicit parameters.
>

Maybe this is skirting too loose to the dynamic scoping, but maybe
ContextFrame? This does start to line up with frames of execution which I
know is a bit low-level, but then again most people will never need to know
about this corner of Python.

-brett


> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 550 v3

2017-08-20 Thread Guido van Rossum 
>
> On Sun, Aug 20, 2017, 03:08 Antoine Pitrou  wrote:
>
>> On Sat, 19 Aug 2017 17:21:03 -0700
>> Guido van Rossum  wrote:
>> > The way we came to "logical context" was via "logical thread (of
>> control)",
>> > which is distinct from OS thread. But I think we might need to search
>> for
>> > another term...
>>
>> Perhaps "task context"?  A "task" might be a logical thread, OS thread,
>> or anything else that deserves a distinct set of implicit parameters.
>>
>
I think you're on to something here, though I hesitate to use "task"
because asyncio.Task is a specific implementation of it.

On Sun, Aug 20, 2017 at 7:04 PM, Brett Cannon  wrote:

> Maybe this is skirting too loose to the dynamic scoping, but maybe
> ContextFrame? This does start to line up with frames of execution which I
> know is a bit low-level, but then again most people will never need to know
> about this corner of Python.
>

I've been thinking that the missing link here may be the execution stack. A
logical thread (LT) has a "logical stack" (LS). While a thread of control
is a fairly fuzzy concept (once you include things that aren't OS threads),
an execution stack is a concrete object, even if not all logical threads
represent their execution stack in the same way. For example, a suspended
asyncio Task has a stack that is represented by a series of stack frames
linked together by await (or yield from), and greenlet apparently uses a
different representation again (their term is micro-thread -- maybe we
could also do something with that?).

Here's the result of some more thinking about this PEP that I've been doing
while writing and rewriting this message (with a surprising ending).

Let's say that the details of scheduling an LT and managing its mapping
onto an LS is defined by a "framework". In this terminology, OS threads are
a framework, as are generators, asyncio, and greenlet. There are
potentially many different such frameworks. (Some others include Twisted,
Tornado and concurrent.futures.ThreadPoolExecutor.)

The PEP's big idea is to recognize that there are also many different,
non-framework, libraries (e.g. Decimal or Flask) that need to associate
some data with an LT. The PEP therefore proposes APIs that allow libraries
to do this without caring about what framework is managing the LT, and vice
versa (the framework doesn't have to care about how libraries use the
per-LT data).

The proposed APIs uses two sets of concepts: one set for the framework and
one for the library.

The library-facing API is simple: create a ContextKey (CK) instance as a
global variable in the library, and use its get() and set() methods to
access and manipulate the data for that library associated with the current
logical thread (LT). Its role is similar to threading.local(), although the
API and implementation are completely different, and threading.local() is
tied to a specific framework (OS threads).

For frameworks the API is more complicated. There are two new classes,
LogicalContext (LC) and ExecutionContext (EC). The PEP gives pseudo code
suggesting that LC is/contains a dict (whose items are (CK, value) pairs)
and an EC is/contains a list of LCs. But in actuality that's only one
possible implementation (and not the one proposed for CPython). The key
idea is rather that a framework needs to be able to take the data
associated with one LT and clone it as the starting point for the data
associated for a new LT. This cloning is done by
sys.get_execution_context(), and the PEP proposes to use a Hash Array
Mapped Trie (HAMT) as the basis for the implementation of LC and EC, to
make this cloning fast. IIUC it needs to be fast to match the speed with
which many frameworks create and destroy their LTs.

The PEP proposes a bunch of new functions in sys for frameworks to
manipulate LCs and ECs and their association with the current OS-level
thread. Note that OS threads are important here because in the end all
frameworks build on top of them.

Honestly I'm not sure we need the distinction between LC and EC. If you
read carefully some of the given example code seems to confuse them. If we
could get away with only a single framework-facing concept, I would be
happy calling it ExecutionContext.

(Another critique of the proposal I have is that it adds too many
similarly-named functions to sys. But this email is already too long and I
need to go to bed.)

-- 
--Guido van Rossum (python.org/~guido )
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 550 v3 naming

2017-08-20 Thread Jim J. Jewett 
Building on Brett's suggestion:

FrameContext: used in/writable by one frame
ContextStack: a FrameContext and its various fallbacks

-jJ
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com