Skip to content

Conversation

nanjekyejoannah
Copy link
Contributor

@nanjekyejoannah nanjekyejoannah commented Mar 6, 2020

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

Copy link
Contributor

@aeros aeros left a 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.

Comment on lines +25 to +28
.. method:: is_running()

Return whether or not the identified interpreter is running.
It returns `True` and `False` otherwise.
Copy link
Contributor

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.

Comment on lines +30 to +33
.. method:: destroy()

Destroy the interpreter. Attempting to destroy the current
interpreter results in a `RuntimeError`.
Copy link
Contributor

@aeros aeros Mar 8, 2020

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?

Comment on lines +61 to +65
.. 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.
Copy link
Contributor

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)

Comment on lines +100 to +102
.. method:: send_buffer_nowait(obj)

Like ``send_buffer()`` but return ``False`` if not received.
Copy link
Contributor

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
results in a ``ChannelClosedError`` exception.
results in a :exc:`ChannelClosedError`.

Comment on lines +129 to +131
.. function:: list_all_channels()

Return all open channels.
Copy link
Contributor

@aeros aeros Mar 8, 2020

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.

Comment on lines +133 to +136
.. function:: create()

Initialize a new (idle) Python interpreter. Get the currently
running interpreter. This method returns an ``Interpreter`` object.
Copy link
Contributor

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?

@aeros aeros added the type-feature A feature request or enhancement label Mar 8, 2020
@vstinner vstinner changed the title bpo-39881: Multiple Interpreters in the Stdlib (PEP 554) bpo-32604: Multiple Interpreters in the Stdlib (PEP 554) May 15, 2020
@vstinner
Copy link
Member

vstinner commented May 15, 2020

I marked bpo-39881 as a duplicate of bpo-32604. I changed this PR title to use bpo-32604.

@erlend-aasland erlend-aasland changed the title bpo-32604: Multiple Interpreters in the Stdlib (PEP 554) gh-76785: Multiple Interpreters in the Stdlib (PEP 554) Jan 12, 2024
@erlend-aasland
Copy link
Contributor

This PR should be retargeted to PEP-734.

@python-cla-bot
Copy link

The following commit authors need to sign the Contributor License Agreement:

CLA signed

@StanFromIreland
Copy link
Member

Completed in: #133958

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting core review type-feature A feature request or enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants