Skip to content

bpo-38159: Clarify documentation of PyState_AddModule#16101

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.

Sign up for GitHub

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

Merged
encukou merged 4 commits into from
Nov 1, 2019
Merged

bpo-38159: Clarify documentation of PyState_AddModule #16101

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
46cc296
Clarify documentation of PyState_AddModule
encukou Sep 13, 2019
96a53b2
Point out that Python only calls PyState_AddModule after a module is …
encukou Sep 24, 2019
8dddb47
Apply Nick's suggestions
encukou Oct 22, 2019
904535b
Wrap lines
encukou Oct 22, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions Doc/c-api/module.rst
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -485,10 +485,21 @@ since multiple such modules can be created from a single definition.

Only effective on modules created using single-phase initialization.

Python calls ``PyState_AddModule`` automatically after importing a module,

@eduardo-elizondoeduardo-elizondoSep 24, 2019

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

An alternate implementation might not necessarily call PyState_AddModule but still achieve the same end result. Perhaps just say that Python attaches the module to the interpreter state and should be accessible through PyState_FindModule. How they achieve that should be up to the implementation

@encukouencukouSep 25, 2019

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

All ways I can find of wording this more precisely make it significantly harder to understand.

I think it's understood that alternate implementations are free to do an equivalent of calling PyState_AddModule, instead of actually calling it. They should still implement the PyState_AddModule semantics (unless they decide to differ, of course).

Another thing that's implied here is that Python only calls this on single-phase-init modules. And another is that it's idempotent.

Should we document all that? How much hand-holding do authors of alternative import mechanisms need? (This is a real question, which you are in a good position to answer.)

@encukouencukouOct 8, 2019

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

But my main issue is:

All ways I can find of wording this more precisely make it significantly harder to understand.

If you can think of a better way, let me know! Otherwise I can merge this.

so it is unnecessary (but harmless) to call it from module initialization
code. An explicit call is needed only if the module's own init code
subsequently calls ``PyState_FindModule``.
The function is mainly intended for implementing alternative import
mechanisms (either by calling it directly, or by referring to its
implementation for details of the required state updates).

Return 0 on success or -1 on failure.

.. versionadded:: 3.3

.. c:function:: int PyState_RemoveModule(PyModuleDef *def)

Removes the module object created from *def* from the interpreter state.
Return 0 on success or -1 on failure.

.. versionadded:: 3.3