<p dir="ltr"><br>
On 15 May 2015 05:04, "Petr Viktorin" <<a href="mailto:encukou@gmail.com">encukou@gmail.com</a>> wrote:<br>
><br>
> On Thu, May 14, 2015 at 6:45 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> > On 14 May 2015 at 22:38, Petr Viktorin <<a href="mailto:encukou@gmail.com">encukou@gmail.com</a>> wrote:<br>
> >> Allowing PyInit to optionally return PyModuleDef is a bit of a hack,<br>
> >> but it keeps the details isolated between the module and the import<br>
> >> machinery.<br>
> >> PyModuleDef is a PyObject, so the PyInit signature matches. Just the<br>
> >> PyInit name is a bit misleading :(<br>
> ><br>
> > Agreed it makes the name of PyInit_* a bit misleading, but also agreed<br>
> > that it sounds like a good trick for making this work in a way that<br>
> > can handle _PyImport_inittab appropriately.<br>
> ><br>
> > In terms of documenting it in a way that lets the hook name still make<br>
> > sense, perhaps we can refer to returning PyModuleDef as "multi-phase<br>
> > initialisation"? That is:<br>
> ><br>
> > - initialise the module definition<br>
> > - create the module object<br>
> > - execute the module body<br>
><br>
> Yes! That'll even make a much better name for the PEP; currently it<br>
> reads like "yet another change".<br>
> (I hope I can rename a PEP once submitted?)</p>
<p dir="ltr">Yes, renaming is fine. That's one of the advantages of using PEP numbers in their permanent URLs, rather than their names.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">P.S. I think this change makes this PEP another fine example of why reference implementations are such an important part of the process - they usually uncover issues and implications that *nobody* had thought of yet :)</p>