<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 8, 2012 at 10:00 AM, Stefan Behnel <span dir="ltr"><<a href="mailto:stefan_ml@behnel.de" target="_blank">stefan_ml@behnel.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Brett,<br>
<br>
thanks for the feedback.<br>
<br>
Brett Cannon, 08.11.2012 15:41:<br>
<div class="im">> On Thu, Nov 8, 2012 at 7:47 AM, Stefan Behnel wrote:<br>
>> I propose to split the extension module initialisation into two steps in<br>
>> Python 3.4, in a backwards compatible way.<br>
>><br>
>> Step 1: The current module init function can be reduced to just creating<br>
>> the module instance and returning it (and potentially doing some simple C<br>
>> level setup). Optionally, after creating the module (and this is the new<br>
>> part), the module init code can register a C callback function that will be<br>
>> called after setting up the module.<br>
><br>
> Why even bother with the module creation? Why can't Python do that as well<br>
> and then call the callback?<br>
><br>
><br>
>> Step 2: The shared library importer receives the module instance from the<br>
>> module init function, adds __file__, __path__, __package__ and friends to<br>
>> the module dict, and then checks for the callback. If non-NULL, it calls it<br>
>> to continue the module initialisation by user code.<br>
</div>> [...]<br>
<div class="im">> An alternative to the alternative is that if the PyInit2 function exists<br>
> it's called instead of the the PyInit function, and then the PyInit<br>
> function is nothing more than a single line function call (or whatever the<br>
> absolute bare minimum is) into some helper that calls the PyInit2 call<br>
> properly for backwards ABI compatibility (i.e. passes in whatever details<br>
> are lost by the indirection in function call). That provides an eventual<br>
> upgrade path of dropping PyInit and moving over to PyInit2.<br>
<br>
</div>In that case, you'd have to export the PyModuleDef descriptor as well,<br>
because that's what tells CPython how the module behaves and what to do<br>
with it to set it up properly (e.g. allocate module state space on the heap).<br></blockquote><div><br></div><div>True.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
In fact, if the module init function became a field in the descriptor, it<br>
would be enough (taking backwards compatibility aside) if *only* the<br>
descriptor was exported and used by the module loader.<br>
<br></blockquote><div><br></div><div>Also true.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With the caveat that this might kill some less common but not necessarily<br>
illegitimate use cases that do more than just creating and initialising a<br>
single module...<br></blockquote><div><br></div><div>You mean creating another module in the init function? That's fine, but that should be a call to __import__ anyway and that should handle things properly. Else you are circumventing the import system and you can do everything from scratch. I don't see why this would stop you from doing anything you want, it just simplifies the common case. </div>

</div></div>