RetroSearch Browse

Tue Aug 29 13:16:50 EDT 2017 · https://mail.python.org/pipermail/python-dev/2017-August/149054.html

On Tue, Aug 29, 2017 at 10:47 AM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Aug 29, 2017 at 6:46 AM, Elvis Pranskevichus <elprans at gmail.com>
> 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 <ncoghlan at gmail.com>
>> 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)
>     <DO STUFF>
>     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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2017-August/149054.html below:

[Python-Dev] Pep 550 module