<p dir="ltr"><br>
On 11 Aug 2013 09:55, "Stefan Behnel" <<a href="mailto:stefan_ml@behnel.de">stefan_ml@behnel.de</a>> wrote:<br>
><br>
> Nick Coghlan, 11.08.2013 15:19:<br>
> > On 11 Aug 2013 09:02, "Stefan Behnel" wrote:<br>
> >>> BTW, this already suggests a simple module initialisation interface. The<br>
> >>> extension module would expose a function that returns a module type, and<br>
> >>> the loader/importer would then simply instantiate that. Nothing else is<br>
> >>> needed.<br>
> >><br>
> >> Actually, strike the word "module type" and replace it with "type". Is<br>
> >> there really a reason why Python needs a module type at all? I mean, you<br>
> >> can stick arbitrary objects in sys.modules, so why not allow arbitrary<br>
> >> types to be returned by the module creation function?<br>
> ><br>
> > That's exactly what I have in mind, but the way extension module imports<br>
> > currently work means we can't easily do it just yet. Fortunately, importlib<br>
> > means we now have some hope of fixing that :)<br>
><br>
> Well, what do we need? We don't need to care about existing code, as long<br>
> as the current scheme is only deprecated and not deleted. That won't happen<br>
> before Py4 anyway. New code would simply export a different symbol when<br>
> compiling for a CPython that supports it, which points to the function that<br>
> returns the type.<br>
><br>
> Then, there's already the PyType_Copy() function, which can be used to<br>
> create a heap type from a statically defined type. So extension modules can<br>
> simply define an (arbitrary) additional type in any way they see fit, copy<br>
> it to the heap, and return it.<br>
><br>
> Next, we need to define a signature for the type's __init__() method.</p>
<p dir="ltr">We need the "ModuleSpec" object to pass here, which is what we're currently working on in import-sig.</p>
<p dir="ltr">We're not going to define something specifically for C extensions when other modules suffer related problems.</p>
<p dir="ltr">Cheers,<br>
Nick.<br></p>
<p dir="ltr">This<br>
> can be done in a future proof way by allowing arbitrary keyword arguments<br>
> to be added, i.e. such a type must have a signature like<br>
><br>
>     def __init__(self, currently, used, pos, args, **kwargs)<br>
><br>
> and simply ignore kwargs for now.<br>
><br>
> Actually, we may get away with not passing all too many arguments here if<br>
> we allow the importer to add stuff to the type's dict in between,<br>
> specifically __file__, __path__ and friends, so that they are available<br>
> before the type gets instantiated. Not sure if this is a good idea, but it<br>
> would at least relieve the user from having to copy these things over from<br>
> some kind of context or whatever we might want to pass in.<br>
><br>
> Alternatively, we could split the instantiation up between tp_new() and<br>
> tp_init(), and let the importer set stuff on the instance dict in between<br>
> the two. But given that this context won't actually change once the shared<br>
> library is loaded, the only reason to prefer modifying the instance instead<br>
> of the type would be to avoid requiring a tp_dict for the type. Open for<br>
> discussion, I guess.<br>
><br>
> Did I forget anything? Sounds simple enough to me so far.<br>
><br>
> Stefan<br>
><br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-dev">http://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>