-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gh-76785: Multiple Interpreters in the Stdlib (PEP 554) #18817
base: main
Are you sure you want to change the base?
Conversation
Co-Authored-By: Eric Snow <ericsnowcurrently@gmail.com>
Co-Authored-By: Eric Snow <ericsnowcurrently@gmail.com>
Co-Authored-By: Eric Snow <ericsnowcurrently@gmail.com>
Co-Authored-By: Eric Snow <ericsnowcurrently@gmail.com>
Co-Authored-By: Eric Snow <ericsnowcurrently@gmail.com>
Co-Authored-By: Eric Snow <ericsnowcurrently@gmail.com>
Co-Authored-By: Eric Snow <ericsnowcurrently@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this @nanjekyejoannah! As someone who hasn't extensively worked with subinterpreters (mainly since it was only available through the C-API), I greatly look forward to exploring their various use cases and experimenting with them as model of concurrency. :)
I have some general suggestions regarding the documentation; I'll try to add some additional ones as I find the time.
.. method:: is_running() | ||
|
||
Return whether or not the identified interpreter is running. | ||
It returns `True` and `False` otherwise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, this could be better phrased as:
Return `True` if the identified interpreter is running.
For comparison, see https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.is_running or https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Future.cancelled.
.. method:: destroy() | ||
|
||
Destroy the interpreter. Attempting to destroy the current | ||
interpreter results in a `RuntimeError`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC, it also results in a RuntimeError
if an interpreter is attempted to be destroyed which is presently running (from my recollection of the C-API function, interp_destroy()
). Could this also be mentioned?
.. method:: release() | ||
|
||
Release the channel for the current interpreter. | ||
By default both ends are released. Releasing an already | ||
released end results in a ``ChannelReleasedError`` exception. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, the second sentence could be better phrased as:
Releasing an end more than once results in a
:exc:`ChannelReleasedError`.
(Also added a Sphinx role, which should generate an inline link to the exception definition below)
.. method:: send_buffer_nowait(obj) | ||
|
||
Like ``send_buffer()`` but return ``False`` if not received. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my above comment on send_nowait()
.
|
||
Close the channel in all interpreters. By default | ||
both ends are closed. closing an already closed end | ||
results in a ``ChannelClosedError`` exception. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
results in a ``ChannelClosedError`` exception. | |
results in a :exc:`ChannelClosedError`. |
.. function:: list_all_channels() | ||
|
||
Return all open channels. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this return a list of Channel objects or something else? I think it would be helpful to mention that here.
.. function:: create() | ||
|
||
Initialize a new (idle) Python interpreter. Get the currently | ||
running interpreter. This method returns an ``Interpreter`` object. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was "Get the currently running interpreter" accidentally included here?
Co-authored-by: Kyle Stanley <aeros167@gmail.com>
Co-authored-by: Kyle Stanley <aeros167@gmail.com>
This PR should be retargeted to PEP-734. |
This is the initial implementation of the high-level part of PEP 554.
I have added some changes from #17323 by @LewisGaul to aid have the ability to List interpreters associated with a channel end.
Co-author : Lewis Gaul.
cc @ericsnowcurrently @vstinner
https://bugs.python.org/issue39881