[Python-Dev] PEP 567 v3

Guido van Rossum gvanrossum at gmail.com
Wed Jan 17 14:24:34 EST 2018


Perhaps you can update the PEP with a summary of the rejected ideas from
this thread?

On Jan 17, 2018 7:23 AM, "Yury Selivanov" <yselivanov.ml at gmail.com> wrote:

> On Wed, Jan 17, 2018 at 6:03 AM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
> > On Tue, 16 Jan 2018 17:18:06 -0800
> > Nathaniel Smith <njs at pobox.com> wrote:
> >> On Tue, Jan 16, 2018 at 5:06 PM, Yury Selivanov <
> yselivanov.ml at gmail.com> wrote:
> >> >
> >> > I think it would be a very fragile thing In practice: if you have even
> >> > one variable in the context that isn't pickleable, your code that uses
> >> > a ProcessPool would stop working.  I would defer Context pickleability
> >> > to 3.8+.
> >>
> >> There's also a more fundamental problem: you need some way to match up
> >> the ContextVar objects across the two processes, and right now they
> >> don't have an attached __module__ or __qualname__.
> >
> > They have a name, though.  So perhaps the name could serve as a unique
> > identifier?  Instead of being serialized as a bunch of ContextVars, the
> > Context would then be serialized as a {name: value} dict.
>
> One of the points of the ContextVar design is to avoid having unique
> identifiers requirement. Names can clash which leads to data being
> lost. If you prohibit them from clashing, then if libraries A and B
> happen to use the same context variable name—you can't use them both
> in your projects.  And without enforcing name uniqueness, your
> approach to serialize context as a dict with string keys won't work.
>
> I like Nathaniel's idea to explicitly enable ContextVars pickling
> support on a per-var basis.  Unfortunately we don't have time to
> seriously consider and debate (and implement!) this idea in time
> before the 3.7 freeze.
>
> In the meanwhile, given that Context objects are fully introspectable,
> users can implement their own ad-hoc solutions for serializers or
> cross-process execution.
>
> Yury
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180117/030e8e5e/attachment.html>


More information about the Python-Dev mailing list