Re: PEP 489: Redesigning extension module loading

On 31 March 2015 at 22:49, Petr Viktorin <[email protected]> wrote:
> On 03/30/2015 03:21 PM, Nick Coghlan wrote:
> Also, some modules wrap a library that has global state (haven't checked
> stdlib, but curses, readline, locale are candidates).
> It doesn't make sense to allow loading more instances of such modules.
> Perhaps there should be a flag to distinguish them? Or just let them use
> PyState_AddModule/PyState_FindModule to prevent re-import?
>
> The need for flags would be a good argument to after all have a ModuleExport
> structure wrapping around slots. Such a structure could also share
> PyModuleDef_Base, making it usable with PyState_AddModule/PyState_FindModule
> (there'd be new functions, but the machinery/data structure could be
> reused). So I'm starting to be more inclined to do this again:
>
> typedef struct PyModule_Export {
>   PyModuleDef_Base m_base;
>   const char* m_doc;
>   int m_flags;
>   PyModule_Slot *m_slots; /* terminated by slot==0. */
> } PyModule_Export;

The flag variable on types has proven useful many times, so that does
sound potentially valuable here. For the specific case you're talking
about, we could have a "PyModule_EXPORT_SINGLETON" flag that caused
the import machinery to automatically call
PyState_AddModuleFromExport() (or whatever the new function was
called)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia