classification
Title: Make C-API docs clear about what the "main" interpreter is
Type: Stage: resolved
Components: Documentation Versions: Python 3.9, Python 3.8
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: nanjekyejoannah Nosy List: eric.snow, nanjekyejoannah, ncoghlan
Priority: normal Keywords: patch

Created on 2019-03-30 15:55 by nanjekyejoannah, last changed 2019-08-02 17:49 by eric.snow. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 12666 merged nanjekyejoannah, 2019-04-02 19:21
PR 15080 merged miss-islington, 2019-08-02 15:55
Messages (6)
msg339207 - (view) Author: Joannah Nanjekye (nanjekyejoannah) * (Python committer) Date: 2019-03-30 15:55
Following up a discussion on a PR here : https://github.com/python/cpython/pull/12238, There is need to make sure the C-API docs are clear about what the "main" interpreter is.
msg339508 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2019-04-05 17:27
I should have added something like this earlier, but here are key points to consider covering:

* "main" interpreter is the original, created when the runtime initializes
* historically almost always the only Python interpreter in a process
    * this is changing (more projects using subinterpreters, PEP 554)
    * in the "python" executable, subinterpreters available via extension modules (but uncommon)
* it has extra responsiblities:
    * signal handling, in main thread
    * "pending calls", in main thread
        * not necessarily something to publicize :)
    * running in the "main" thread
        * can be taken over by a sub-interpreter, but not likely
    * execution *during* runtime initialization
    * usually (always?) the active interpreter during runtime finalization
    * others?
* no strong link between interpreters (e.g. main <--> sub <--> sub)
    * no record of what interpreter was active (if any) when a subinterpreter was created
    * no "parent" interpreter
    * thread states may share thread ID
* a bunch of stuff in the C-API and in the runtime still assumes that the main interpreter is running in the current OS thread
* other stuff?


Not all of that necessarily belongs there in the docs, but a lot of it does. :)
msg339509 - (view) Author: Joannah Nanjekye (nanjekyejoannah) * (Python committer) Date: 2019-04-05 17:32
Thanks for this feedback. Let me see how I can incorporate this in the PR.
msg348904 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2019-08-02 15:50
New changeset 854d0a4b98b13629252e21edaf2b785b429e5135 by Eric Snow (Joannah Nanjekye) in branch 'master':
bpo-36487: Make C-API docs  clear about what the main interpreter is. (gh-12666)
https://github.com/python/cpython/commit/854d0a4b98b13629252e21edaf2b785b429e5135
msg348906 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2019-08-02 15:54
Thanks, Joannah!
msg348909 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2019-08-02 17:49
New changeset 375f35be0688da0fc0f27afc4faea76590d7c24d by Eric Snow (Miss Islington (bot)) in branch '3.8':
bpo-36487: Make C-API docs clear about what the main interpreter is. (gh-15080)
https://github.com/python/cpython/commit/375f35be0688da0fc0f27afc4faea76590d7c24d
History
Date User Action Args
2019-08-02 17:49:41eric.snowsetmessages: + msg348909
2019-08-02 15:55:10miss-islingtonsetpull_requests: + pull_request14826
2019-08-02 15:54:28eric.snowsetstatus: open -> closed
versions: + Python 3.9
messages: + msg348906

resolution: fixed
stage: patch review -> resolved
2019-08-02 15:50:31eric.snowsetmessages: + msg348904
2019-04-05 17:32:06nanjekyejoannahsetmessages: + msg339509
2019-04-05 17:27:11eric.snowsetnosy: + ncoghlan
messages: + msg339508
2019-04-02 19:21:06nanjekyejoannahsetkeywords: + patch
stage: patch review
pull_requests: + pull_request12594
2019-04-02 18:20:43nanjekyejoannahsetcomponents: + Documentation
versions: + Python 3.8
2019-04-01 15:07:56eric.snowsetnosy: + eric.snow
2019-03-30 15:56:18nanjekyejoannahsetassignee: nanjekyejoannah
2019-03-30 15:55:50nanjekyejoannahcreate