[Import-SIG] PEP 489: Redesigning extension module loading; version 4

Petr Viktorin encukou at gmail.com
Thu May 14 10:10:51 CEST 2015


On Wed, May 13, 2015 at 6:04 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 14 May 2015 at 00:31, Petr Viktorin <encukou at gmail.com> wrote:
>> Or, I could keep the "PyInit_*" hook name, and allow it to return
>> PyModuleDef instead of a module. This is obviously a hack, and would
>> force me to get back down to the drawing board, but considering the
>> options it seems best to explore this option.
>> (PyInit_* and PyModuleExport_* signatures are technically compatible,
>> since a PyModuleDef is a PyObject)
>>
>> I'd welcome your thoughts.
>
> Would it be feasible to go with a model where _PyImport_inittab
> continues to be based on the legacy extension module initialisation
> system for the time being? That would mean implementing PyInit_* would
> remain required rather than optional for 3.5, but lots of folks are
> going to want to provide it anyway for compatibility with 3.4 and
> earlier.

That doesn't really solve the problem, just delays it until we decide
that PyInit_* is really optional.
It would mean you couldn't take advantage of the improvements in PEP
489 (create/exec split and ModuleSpec). You'd just write more
boilerplate for no benefit (except small stuff like non-ASCII module
names).

What might be worse, it would mean that modules would have different
behavior depending on whether they're frozen or not, which would
probably result in subtle bugs you'd only find when creating frozen
binaries.


More information about the Import-SIG mailing list