Re: [Python-Dev] Pep 550 module

[Yury Selivanov]

On Tue, Aug 29, 2017 at 10:47 AM, Guido van Rossum  wrote:
> On Tue, Aug 29, 2017 at 6:46 AM, Elvis Pranskevichus 
> wrote:
>>
>> On Tuesday, August 29, 2017 9:14:53 AM EDT Yury Selivanov wrote:
>> > On Tue, Aug 29, 2017 at 6:53 AM, Nick Coghlan 
>> wrote:
>> > > Given the refocusing of the PEP on the context variable API, with
>> > > the
>> > > other aspects introduced solely in service of making context
>> > > variables work as defined, my current suggestion would be to make
>> > > it a hybrid Python/C API using the "contextvars" + "_contextvars"
>> > > naming convention.
>> > >
>> > > Then all most end user applications defining context variables would
>> > >
>> > > need is the single line:
>> > > from contextvars import new_context_var
>> >
>> > I like it!
>> >
>> > +1 from me.
>>
>> +1
>
>
> OK, but does it have to look like a factory function? Can't it look like a
> class? E.g.
>
> from contextvars import ContextVar
>
> my_parameter = ContextVar()
>
> async def some_calculation():
> my_parameter.set(my_parameter.get() + 2)
> 
> my_parameter.delete()

I initially designed the API to be part of the sys module, which
doesn't have any classes and has only functions.

Having ContextVar class exposed directly in the contextvars module
makes sense.  We can also replace new_execution_context() and
new_logical_context() with contextvars.ExecutionContext() and
contextvars.LogicalContext().

Yury
___
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

Re: [Python-Dev] Pep 550 module

[Guido van Rossum]

On Tue, Aug 29, 2017 at 6:46 AM, Elvis Pranskevichus 
wrote:

> On Tuesday, August 29, 2017 9:14:53 AM EDT Yury Selivanov wrote:
> > On Tue, Aug 29, 2017 at 6:53 AM, Nick Coghlan 
> wrote:
> > > Given the refocusing of the PEP on the context variable API, with
> > > the
> > > other aspects introduced solely in service of making context
> > > variables work as defined, my current suggestion would be to make
> > > it a hybrid Python/C API using the "contextvars" + "_contextvars"
> > > naming convention.
> > >
> > > Then all most end user applications defining context variables would
> > >
> > > need is the single line:
> > > from contextvars import new_context_var
> >
> > I like it!
> >
> > +1 from me.
>
> +1
>

OK, but does it have to look like a factory function? Can't it look like a
class? E.g.

from contextvars import ContextVar

my_parameter = ContextVar()

async def some_calculation():
my_parameter.set(my_parameter.get() + 2)

my_parameter.delete()

-- 
--Guido van Rossum (python.org/~guido )
___
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

Re: [Python-Dev] Pep 550 module

[Elvis Pranskevichus]

On Tuesday, August 29, 2017 9:14:53 AM EDT Yury Selivanov wrote:
> On Tue, Aug 29, 2017 at 6:53 AM, Nick Coghlan  
wrote:
> > On 28 August 2017 at 01:51, Jim J. Jewett  
wrote:
> >> I think there is general consensus that this should go in a module
> >> other than sys. (At least a submodule.)
> >> 
> >> The specific names are still To Be Determined, but I suspect seeing
> >> the functions and objects as part of a named module will affect
> >> what works.> 
> > Given the refocusing of the PEP on the context variable API, with
> > the
> > other aspects introduced solely in service of making context
> > variables work as defined, my current suggestion would be to make
> > it a hybrid Python/C API using the "contextvars" + "_contextvars"
> > naming convention.
> > 
> > Then all most end user applications defining context variables would
> > 
> > need is the single line:
> > from contextvars import new_context_var
> 
> I like it!
> 
> +1 from me.

+1
___
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

Re: [Python-Dev] Pep 550 module

[Yury Selivanov]

On Tue, Aug 29, 2017 at 6:53 AM, Nick Coghlan  wrote:
> On 28 August 2017 at 01:51, Jim J. Jewett  wrote:
>> I think there is general consensus that this should go in a module other
>> than sys. (At least a submodule.)
>>
>> The specific names are still To Be Determined, but I suspect seeing the
>> functions and objects as part of a named module will affect what works.
>
> Given the refocusing of the PEP on the context variable API, with the
> other aspects introduced solely in service of making context variables
> work as defined, my current suggestion would be to make it a hybrid
> Python/C API using the "contextvars" + "_contextvars" naming
> convention.
>
> Then all most end user applications defining context variables would
> need is the single line:
>
> from contextvars import new_context_var

I like it!

+1 from me.

Yury
___
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

Re: [Python-Dev] Pep 550 module

[Nick Coghlan]

On 28 August 2017 at 01:51, Jim J. Jewett  wrote:
> I think there is general consensus that this should go in a module other
> than sys. (At least a submodule.)
>
> The specific names are still To Be Determined, but I suspect seeing the
> functions and objects as part of a named module will affect what works.

Given the refocusing of the PEP on the context variable API, with the
other aspects introduced solely in service of making context variables
work as defined, my current suggestion would be to make it a hybrid
Python/C API using the "contextvars" + "_contextvars" naming
convention.

Then all most end user applications defining context variables would
need is the single line:

from contextvars import new_context_var

_contextvars would contain the APIs that only the interpreter itself
can implement, while contextvars would provide a home for any pure
Python convenience APIs that could be shared across interpreter
implementations.

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

Re: [Python-Dev] Pep 550 module

[Joao S. O. Bueno]

Well, this talk may be a bit of bike-shedding, but

+1 for a separate module/sub module

And full -1 for something named

"dynscopevars"

That word is unreadable, barely mnemonic, but plain "ugly" - (I know that
this is  subjective, but it is just that :-) )

Why not just "execution_context"  or "sys.execution_context" ?

"from execution_context import Var, lookup, set, LogicalContext, run_with  "






On 27 August 2017 at 12:51, Jim J. Jewett  wrote:

> I think there is general consensus that this should go in a module other
> than sys. (At least a submodule.)
>
> The specific names are still To Be Determined, but I suspect seeing the
> functions and objects as part of a named module will affect what works.
>
> So I am requesting that the next iteration just pick a module name, and
> let us see how that looks.  E.g
>
> import dynscopevars
>
> user=dynscopevars.Var ("username")
>
> myscope=dynscopevars.get_current_scope()
>
> childscope=dynscopevars.Scope (parent=myscope,user="bob")
>
>
> -jJ
>
>
> ___
> 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/
> jsbueno%40python.org.br
>
>
___
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