# PEP 734: Multiple Interpreters in the Stdlib

**URL:** <https://discuss.python.org/t/pep-734-multiple-interpreters-in-the-stdlib/41147>\
**Category:** PEPs\
**Created:** [December 15, 2023, 12:14am UTC](https://discuss.python.org/t/pep-734-multiple-interpreters-in-the-stdlib/41147 "2023-12-15T00:14:10Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\
**Post date:** [December 15, 2023, 10:13am UTC](https://discuss.python.org/t/pep-734-multiple-interpreters-in-the-stdlib/41147/8 "2023-12-15T10:13:44Z")

</div>

I briefly skimmed through the PEP. One thing I have in mind: instead of hardcoding the list of types that support sharing, would it be possible to make this a protocol? Something like ` __reduce__ `, but for in-process sharing.

Also, I think `interpreters.Queue` deviating from the threading and multiprocessing queue semantics by only allowing shareable objects will be annoying users. Perhaps you could have two queue classes, for example a `LowLevelQueue` for shareable objects only, and a regular `Queue` that would use pickle for most objects?

Finally, I think a benchmark of sharing vs. pickling/unpickling would be useful to assess the benefits of the sharing mechanism. Right now it’s not obvious whether this really can make a difference.

(note that with pickle 5 out-of-band buffers, you could perhaps simply share those buffers while still using pickle for most datatypes?)

---

_[View the full topic](https://discuss.python.org/t/pep-734-multiple-interpreters-in-the-stdlib/41147)._