Re: PEP 489: Redesigning extension module loading; version 4

On Thu, May 14, 2015 at 6:45 PM, Nick Coghlan <[email protected]> wrote:
> On 14 May 2015 at 22:38, Petr Viktorin <[email protected]> wrote:
>> Allowing PyInit to optionally return PyModuleDef is a bit of a hack,
>> but it keeps the details isolated between the module and the import
>> machinery.
>> PyModuleDef is a PyObject, so the PyInit signature matches. Just the
>> PyInit name is a bit misleading :(
>
> Agreed it makes the name of PyInit_* a bit misleading, but also agreed
> that it sounds like a good trick for making this work in a way that
> can handle _PyImport_inittab appropriately.
>
> In terms of documenting it in a way that lets the hook name still make
> sense, perhaps we can refer to returning PyModuleDef as "multi-phase
> initialisation"? That is:
>
> - initialise the module definition
> - create the module object
> - execute the module body

Yes! That'll even make a much better name for the PEP; currently it
reads like "yet another change".
(I hope I can rename a PEP once submitted?)

>> Somewhat related: any thoughts on the legacy init example code [0]?
>> You asked for an example like this; is it what you had in mind? If you
>> compile this with a PEP-489 Python with the stable API, the .so can be
>> used with older Pythons as well.
>> I now think it's a bit silly: it would be enough to use #ifdef: define
>> either PyModuleExport or PyInit, depending on the Python version.
>> This won't do if you're targetting the stable API, but in that case
>> you can't use any of the new PEP 489 features anyway, so it's enough
>> to only define PyInit.
>> Or is there something I missed?
>
> I think the idea above makes it mandatory to use "#ifdef" to request
> multi-phase initialisation on 3.5+ and single-phase initialisation on
> earlier versions. An example of the relevant incantations might still
> be useful though.

Definitely.