[Import-SIG] PEP 489: Redesigning extension module loading
Nick Coghlan
ncoghlan at gmail.com
Thu Apr 2 12:17:08 CEST 2015
On 31 March 2015 at 22:49, Petr Viktorin <encukou at gmail.com> 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 | ncoghlan at gmail.com | Brisbane, Australia
More information about the Import-SIG
mailing list