-
-
Notifications
You must be signed in to change notification settings - Fork 33.9k
bpo-36487: Make C-API docs clear about what the main interpreter is #12666
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
Conversation
ericsnowcurrently
left a comment
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.
The flow of the text doesn't line up as well with this change. Consider splitting the original paragraph right before the final sentence, like this:
you to do that. You can switch between sub-interpreters using the
+:c:func:`PyThreadState_Swap` function.
+
+<explanation of main interpreter>
+
+You can create and destroy sub-interpreters using the following
+functions:
I've also left a comment for the paragraph about the main interpreter.
Doc/c-api/init.rst
Outdated
| Before sub-interpreters, there is a main interpreter which is the first one | ||
| created by the CPython runtime on startup when the ``python`` command is | ||
| run. The :c:func:`PyInterpreterState_Main` funtion returns a pointer to this | ||
| main interpreter's state. |
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.
This description of the main interpreter could be a bit more direct but the focus should remain within the context of subinterpreters. For instance, there's no need here to mention any specific API related to the main interpreter. Anyway, I've updated the BPO issue with a list of key points to cover.
FWIW, I'm not sure whether it would be better to keep the main-related text small (e.g. one short paragraph) or to make it comprehensive (e.g. across multiple paragraphs). If we go with that latter then it may make sense to have a separate section nearby for the main interpreter.
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.
I think it makes sense to keep things minimal for now, and defer more comprehensive documentation to the resolution of the PEP for a Python level subinterpreter API.
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.
@ncoghlan I agree to this being a small paragraph for now most especially given the current structure of the docs. Though I also have to warn you that incorporating all the points @ericsnowcurrently suggests in the BPO will lead to a big paragraph.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
|
@ericsnowcurrently , I have made some edits. Note: I just made a summary of your suggestions here : https://bugs.python.org/issue36487 it would have had much more detail if it was in a separate section though. PTAL |
ericsnowcurrently
left a comment
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.
That's looking good! Thanks for working on this. I just have a few comments.
ncoghlan
left a comment
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.
I finally figured out how the "Suggestions" UI works :)
(There's a hard-to-describe icon when editing your comments that adds the line you're commenting on with the markup to turn it into a suggested change)
Misc/NEWS.d/next/Documentation/2019-04-02-19-23-00.bpo-36487.Jg6-MG.rst
Outdated
Show resolved
Hide resolved
Co-Authored-By: Nick Coghlan <ncoghlan@gmail.com>
Co-Authored-By: Nick Coghlan <ncoghlan@gmail.com>
|
I have made the requested changes; please review again. |
|
Thanks for making the requested changes! @ericsnowcurrently: please review the changes made to this pull request. |
ericsnowcurrently
left a comment
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 the updates. This is looking good correctness-wise. I've left a few comments with tweaks to clarify a little and to make the paragraph flow a bit more cohesively. If you put them all together, the results looks like this:
The "main" interpreter is the first one created when the runtime initializes.
It is usually the only Python interpreter in a process. Unlike sub-interpreters,
the main interpreter has unique process-global responsibilities like signal
handling. It is also responsible for execution during runtime initialization and
is usually the active interpreter during runtime finalization. The
:c:func:`PyInterpreterState_Main` funtion returns a pointer to its state.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
|
I have made the requested changes; please review again. |
|
Thanks for making the requested changes! @ericsnowcurrently: please review the changes made to this pull request. |
ericsnowcurrently
left a comment
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.
LGTM
Thanks for working on this, @nanjekyejoannah!
|
Thanks @nanjekyejoannah for the PR, and @ericsnowcurrently for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8. |
…ythongh-12666) (cherry picked from commit 854d0a4) Co-authored-by: Joannah Nanjekye <33177550+nanjekyejoannah@users.noreply.github.com>
I have added documentation to clarify on what the main interpreter is.
https://bugs.python.org/issue36487