On 24 August 2017 at 23:52, Barry Warsaw wrote:
> Guido van Rossum wrote:
>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
>>
>> I worry that that's going to lead more people astray thinking this has
>> something to do with contextlib, which it really doesn't (it's much more
>> closely
I think we should let the naming issue go for now, while Yury et al. are
rewriting the PEP. We'll revisit it after we're more comfortable with the
semantics.
On Thu, Aug 24, 2017 at 9:55 PM, Nick Coghlan wrote:
> On 25 August 2017 at 01:00, Guido van Rossum wrote:
> > It shouldn't be called a n
On 25 August 2017 at 01:00, Guido van Rossum wrote:
> It shouldn't be called a namespace unless the dominant access is via
> attributes.
That makes sense.
Since the main purpose of that part of the Python API is to offer an
opaque handle to where the context locals store their values,
something
Barry Warsaw wrote:
I actually
think Python’s scoping rules are fairly easy to grasp,
The problem is that the word "scope", as generally used in
relation to programming languages, has to do with visibility
of names. A variable is "in scope" at a particular point in the
code if you can acccess i
Barry Warsaw wrote:
This is my problem with using "Context" for this PEP. Although I can't
keep up with all names being thrown around,
Not sure whether it helps, but a similar concept in
some Scheme dialects is called a "fluid binding".
e.g. Section 5.4 of http://www.scheme.com/csug8/binding.
On Thu, Aug 24, 2017 at 5:37 AM, Nick Coghlan wrote:
> Migrating a (variant of a) naming subthread from python-ideas over to
> here, does the following sound plausible to anyone else?:
>
> ContextLocal - read/write access API (via get()/set() methods)
> ContextLocalNamespace - active mappi
On Thu, 24 Aug 2017 17:06:09 -0400
Barry Warsaw wrote:
> On Aug 24, 2017, at 16:01, francismb wrote:
> > On 08/24/2017 03:52 PM, Barry Warsaw wrote:
> >> Guido van Rossum wrote:
> >>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
> >>>
> >>> I worry that that's going to lead more
On Aug 24, 2017, at 16:01, francismb wrote:
> On 08/24/2017 03:52 PM, Barry Warsaw wrote:
>> Guido van Rossum wrote:
>>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
>>>
>>> I worry that that's going to lead more people astray thinking this has
>>> something to do with contextlib, whi
Hi,
On 08/24/2017 03:52 PM, Barry Warsaw wrote:
> Guido van Rossum wrote:
>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
>>
>> I worry that that's going to lead more people astray thinking this has
>> something to do with contextlib, which it really doesn't (it's much more
>> closely
On 08/17/2017 05:38 PM, Christian Heimes wrote:
On 2017-08-17 14:21, Cathy Avery wrote:
Hi,
I have a python pull request https://github.com/python/cpython/pull/2489
that introduces AF_VSOCK to the python C socket module. Unfortunately
things have gone quiet for several weeks. Since I am new to
On Thu, Aug 24, 2017 at 8:23 AM, Yury Selivanov wrote:
> Contrary to scoping, the programmer is much less likely to deal with
> Execution Context. How often do we use "threading.local()"?
This is an important point. PEP 550 is targeting library authors,
right? Most folks will not be interactin
On Thu, Aug 24, 2017 at 7:52 AM, Barry Warsaw wrote:
> Guido van Rossum wrote:
>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
>>
>> I worry that that's going to lead more people astray thinking this has
>> something to do with contextlib, which it really doesn't (it's much more
>> clo
On 08/24/2017 06:52 AM, Barry Warsaw wrote:
To me, the functionality proposed in PEP 550 feels more like a "scope"
than a "context". Unlike a lexical scope, it can't be inferred from the
layout of the source code. It's more of a dynamic "execution scope" and
the stacking of "local execution sc
On Thu, Aug 24, 2017 at 10:38 AM, Barry Warsaw wrote:
[..]
I'll snip the naming discussion for now, I'm really curious to see
what other people will say.
> A different tack would more closely align with PEP 550’s heritage in
> thread-local storage, calling these things “execution storage”. I t
On Thu, Aug 24, 2017 at 10:05 AM, Jim J. Jewett wrote:
> On Thu, Aug 24, 2017 at 1:12 AM, Yury Selivanov > On Thu, Aug 24, 2017
> at 12:32 AM, Jim J. Jewett wrote:
>
>> The key requirement for using immutable datastructures is to make
>> "get_execution_context" operation fast.
>
> Do you really n
It shouldn't be called a namespace unless the dominant access is via
attributes.
On Thu, Aug 24, 2017 at 4:37 AM, Nick Coghlan wrote:
> On 24 August 2017 at 08:47, Ethan Furman wrote:
> >
> > ContextVars is actually a different name for LogicalContext. So it would
> > be:
> >
> > ExecutionCo
On 24 August 2017 at 15:38, Barry Warsaw wrote:
> Yes, but in conversations about Python, the term “context” (in the context of
> context managers) comes up way more often than the term “scope”. I actually
> think Python’s scoping rules are fairly easy to grasp, as there aren’t that
> many lev
On Aug 24, 2017, at 10:23, Yury Selivanov wrote:
>
> On Thu, Aug 24, 2017 at 9:52 AM, Barry Warsaw wrote:
>> Guido van Rossum wrote:
>>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
>>>
>>> I worry that that's going to lead more people astray thinking this has
>>> something to do wi
On Thu, Aug 24, 2017 at 9:52 AM, Barry Warsaw wrote:
> Guido van Rossum wrote:
>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
>>
>> I worry that that's going to lead more people astray thinking this has
>> something to do with contextlib, which it really doesn't (it's much more
>> clo
On Thu, Aug 24, 2017 at 1:12 AM, Yury Selivanov > On Thu, Aug 24, 2017
at 12:32 AM, Jim J. Jewett wrote:
> The key requirement for using immutable datastructures is to make
> "get_execution_context" operation fast.
Do you really need the whole execution context, or do you just need
the current v
On Thu, 24 Aug 2017 09:52:47 -0400
Barry Warsaw wrote:
>
> To me, the functionality proposed in PEP 550 feels more like a "scope"
> than a "context".
I would call it "environment" myself, but that risks confusion with
environment variables.
Perhaps "dynamic environment" would remove the confusi
Guido van Rossum wrote:
> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
>
> I worry that that's going to lead more people astray thinking this has
> something to do with contextlib, which it really doesn't (it's much more
> closely related to threading.local()).
This is my problem with
On 24 August 2017 at 08:47, Ethan Furman wrote:
>
> ContextVars is actually a different name for LogicalContext. So it would
> be:
>
> ExecutionContext = [ContextVars()[, ContextVars()[ ...]]]
>
> and you get the (thread.local similar) ContextVars by
>
> context_vars = sys.get_context_vars()
On Thu, Aug 24, 2017 at 1:22 AM, Nick Coghlan wrote:
> On 24 August 2017 at 02:19, Yury Selivanov wrote:
>> I think that "implicit context" is not an accurate description of what
>> LogicalContext is.
>>
>> "implicit context" only makes sense when we talk about decimal
>> context. For instance,
On Wed, Aug 23, 2017 at 9:32 PM, Jim J. Jewett wrote:
>> While the context is defined conceptually as a nested chain of
>> key:value mappings, we avoid using the mapping syntax because of the
>> way the values can shift dynamically out from under you based on who
>> called you
> ...
>> instead of
On 24 August 2017 at 02:19, Yury Selivanov wrote:
> I think that "implicit context" is not an accurate description of what
> LogicalContext is.
>
> "implicit context" only makes sense when we talk about decimal
> context. For instance, in:
>
> Decimal(1) + Decimal(2)
>
> decimal context is im
On Wed, 23 Aug 2017 14:27:55 -0400
Yury Selivanov wrote:
>
> Yeah.. I like TaskContext when it's applied to asynchronous code. It
> doesn't really work for generators because we never refer to
> generators as tasks.
>
> Out of what was proposed so far to replace Logical Context:
>
> 1. DynamicC
27 matches
Mail list logo
