Oh, I like that. It does feel like a property of the variable. (But can you efficiently enumerate all context vars when creating a thread?)

I imagine that thread pools add some complication, because you don’t want to inherit these accidentally between tasks run by the same worker.

On Thu, Aug 19, 2021 at 14:28 Paul Prescod <prescod@gmail.com> wrote:
On Thu, Aug 19, 2021 at 8:43 AM Guido van Rossum <guido@python.org> wrote:
Perhaps we need a library for creating/managing threads that inherits all current context values?

Or is it a "kind of context variable that is shared among threads?" That was more the direction my mind was going.

Context variables that hold explicitly or implicitly immutable values are safe to share. Context variables that hold values intended to be mutated: seldom.

What if it were some kind of ContextVar subclass or flag where you would say you did or didn't want something shared?

And for legacy modules like decimal, you could turn on the flag somehow to get the sharing behaviour.

Sometimes threads are made by third-party libraries and those libraries don't know anything about the context.

 In my case, the pattern was:

1. my code set context variable
2. my code configured a third party library with a callback
3. the third party library used threading for perf reasons
4. it called my callback, which failed due to the context variable failing to be inherited

I believe (after only thinking about it for a day or so) that one can generally determine the right "sharing rule" at the point of definition of a ContextVar, based on the semantics and type of the Var.

On Thu, Aug 19, 2021 at 8:43 AM Guido van Rossum <guido@python.org> wrote:
Perhaps we need a library for creating/managing threads that inherits all current context values?

On Thu, Aug 19, 2021 at 7:48 AM Paul Prescod <prescod@gmail.com> wrote:
There are certain values that are managed independent of any specific code-accessible object. The decimal precision is a good example:

https://docs.python.org/3/library/decimal.html

We can call these context variables. As your code shows, the true "home" of the "prec" value is not some object you manage in your code, but rather some background object called the Context.

The Context is not inherited by sub-threads.

Your code is fine, because you did not use threads. Replace the map with concurrent.futures code (as in my example).

Your code will not work properly anymore. This is the issue.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6YU3RZ6WDWVJI7QEJKICJZN72B5FYOEV/
Code of Conduct: http://python.org/psf/codeofconduct/


--
--Guido van Rossum (python.org/~guido)
--
--Guido (mobile)