<div dir="auto">Perhaps you can update the PEP with a summary of the rejected ideas from this thread?</div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 17, 2018 7:23 AM, "Yury Selivanov" <<a href="mailto:yselivanov.ml@gmail.com">yselivanov.ml@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Jan 17, 2018 at 6:03 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
> On Tue, 16 Jan 2018 17:18:06 -0800<br>
> Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
>> On Tue, Jan 16, 2018 at 5:06 PM, Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com">yselivanov.ml@gmail.com</a>> wrote:<br>
>> ><br>
>> > I think it would be a very fragile thing In practice: if you have even<br>
>> > one variable in the context that isn't pickleable, your code that uses<br>
>> > a ProcessPool would stop working.  I would defer Context pickleability<br>
>> > to 3.8+.<br>
>><br>
>> There's also a more fundamental problem: you need some way to match up<br>
>> the ContextVar objects across the two processes, and right now they<br>
>> don't have an attached __module__ or __qualname__.<br>
><br>
> They have a name, though.  So perhaps the name could serve as a unique<br>
> identifier?  Instead of being serialized as a bunch of ContextVars, the<br>
> Context would then be serialized as a {name: value} dict.<br>
<br>
One of the points of the ContextVar design is to avoid having unique<br>
identifiers requirement. Names can clash which leads to data being<br>
lost. If you prohibit them from clashing, then if libraries A and B<br>
happen to use the same context variable name—you can't use them both<br>
in your projects.  And without enforcing name uniqueness, your<br>
approach to serialize context as a dict with string keys won't work.<br>
<br>
I like Nathaniel's idea to explicitly enable ContextVars pickling<br>
support on a per-var basis.  Unfortunately we don't have time to<br>
seriously consider and debate (and implement!) this idea in time<br>
before the 3.7 freeze.<br>
<br>
In the meanwhile, given that Context objects are fully introspectable,<br>
users can implement their own ad-hoc solutions for serializers or<br>
cross-process execution.<br>
<br>
Yury<br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
</blockquote></div></div>