[docs] Doc - 1.4. The Module’s Method Table and Initialization Function

[Johannes Müller]

Hi,

It seems like there is a small bug (or a missing detail) in the example 
code of the main function in Chapter "1.4. The Module’s Method Table and 
Initialization Function 
<https://docs.python.org/3/extending/extending.html#the-module-s-method-table-and-initialization-function>".

In the example, the return value of PyImport_ImportModule is discarded. 
In my experience, this may cause a crash in Py_Finalize() if the return 
value is discarded and Py_DECREF is omitted.

Is my assumption correct that the example should actually be extended as 
follows?

>     ...
>
>     /* Optionally import the module; alternatively,
>        import can be deferred until the embedded script
>        imports it. */
> PyObject *pModule = PyImport_ImportModule("spam");
>
>     ...
>
>     Py_DECREF(pModule);
>     if (Py_FinalizeEx() < 0) {
>         exit(120);
>     }
>     PyMem_RawFree(program);
>     return 0;

Note that I assume that the developer is supposed to keep a reference of 
the module object, such that the garbage collection cannot free the 
module, while the program is using the interpreter. Is this necessary? 
Or can I be 100% sure that the imported module will exist and do it's 
job until I call Py_FinalizeEx(), even if I don't keep a reference of 
the module, i.e., if I decref pModule directly after importing it?

Regards,
Johannes

PS: In my case, the module is a Python output redirector, that's not 
explicitly used in the executed Python scripts and snippets. It is just 
supposed to redirect the output of the entire Python interpreter until I 
call Py_Finalize.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180904/dd3a06d8/attachment-0001.html>