PEP 734: Multiple Interpreters in the Stdlib

[steve.dower]

@eric.snow

The main reason I went with a Queue-like type is familiarity for users. FWIW, I’m still ruminating over the potential consequences of using pickle by default, particularly as it relates to “sharing” mutable objects.

I think the idea of LowLevelQueue makes a lot of sense here, leaving the Queue name available for a richer version to come later.

You can probably write a recipe for using pickle by default with LowLevelQueue, but I think it’d be a waste to make that the “standard” protocol. We’ll want to be able to define a new __proxy__ or similar (to mirror __reduce__/__getargs__) that knows how to construct an object on the other side assuming the original one still exists (and hence, any native memory/etc. is also available), and that can be part of Queue.

But I think we’re still at the stage where we want 3rd party packages to design the Queue object, and users can use those on each end of the channel. So the PEP right now probably only wants to say we intend to add Queue, but not yet, and add a deliberately simple one as a building block now.