[Python-ideas] New PEP 550: Execution Context

[Yury Selivanov]

Yes, I considered this idea myself, but ultimately rejected it because:

1. Current solution makes it easy to introspect things. Get the
current EC and print it out.  Although the context item idea could be
extended to `sys.create_context_item('description')` to allow that.

2. What if we want to pickle the EC? If all items in it are
pickleable, it's possible to dump the EC, send it over the network,
and re-use in some other process. It's not something I want to
consider in the PEP right now, but it's something that the current
design theoretically allows. AFAIU, `ci = sys.create_context_item()`
context item wouldn't be possible to pickle/unpickle correctly, no?

Some more comments:

On Sat, Aug 12, 2017 at 7:35 PM, Nathaniel Smith <njs at pobox.com> wrote:
[..]
> The advantages are:
> - Eliminates the current PEP's issues with namespace collision; every
> context item is automatically distinct from all others.

TBH I think that the collision issue is slightly exaggerated.

> - Eliminates the need for the None-means-del hack.

I consider Execution Context to be an API, not a collection. It's an
important distinction, If you view it that way, deletion on None is
doesn't look that esoteric.

> - Lets the interpreter hide the details of garbage collecting context values.

I'm not sure I understand how the current PEP design is bad from the
GC standpoint. Or how this proposal can be different, FWIW.

> - Allows for more implementation flexibility. This could be
> implemented directly on top of Yury's current prototype. But it could
> also, for example, be implemented by storing the context values in a
> flat array, where each context item is assigned an index when it's
> allocated.

You still want to have this optimization only for *some* keys. So I
think a separate API is still needed.

Yury