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
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 <jimjjewett@gmail.com> 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
On 28 August 2017 at 01:51, Jim J. Jewett <jimjjewett@gmail.com> 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 | ncoghlan@gmail.com | Brisbane, Australia
On Tue, Aug 29, 2017 at 6:53 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 28 August 2017 at 01:51, Jim J. Jewett <jimjjewett@gmail.com> 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
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@gmail.com> 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
On 28 August 2017 at 01:51, Jim J. Jewett <jimjjewett@gmail.com> wrote: 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
On Tue, Aug 29, 2017 at 6:46 AM, Elvis Pranskevichus <elprans@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@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() -- --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
On Tue, Aug 29, 2017 at 10:47 AM, Guido van Rossum <guido@python.org> wrote:
On Tue, Aug 29, 2017 at 6:46 AM, Elvis Pranskevichus <elprans@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@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
participants (6)
-
Elvis Pranskevichus -
Guido van Rossum -
Jim J. Jewett -
Joao S. O. Bueno -
Nick Coghlan -
Yury Selivanov