<p dir="ltr"><br>
On 11 Aug 2013 09:02, "Stefan Behnel" <<a href="mailto:stefan_ml@behnel.de">stefan_ml@behnel.de</a>> wrote:<br>
><br>
> Stefan Behnel, 11.08.2013 14:53:<br>
> > Stefan Behnel, 11.08.2013 14:48:<br>
> >> Antoine Pitrou, 11.08.2013 14:32:<br>
> >>> On Sun, 11 Aug 2013 14:16:10 +0200 Stefan Behnel wrote:<br>
> >>>>> We<br>
> >>>>> just need to devise a convenience API for that (perhaps by allowing to<br>
> >>>>> create both the subclass *and* instantiate it in a single call).<br>
> >>>><br>
> >>>> Right. This conflicts somewhat with the simplified module creation. If the<br>
> >>>> module loader passed the readily instantiated module instance into the<br>
> >>>> module init function, then module subtypes don't fit into this scheme anymore.<br>
> >>>><br>
> >>>> One more reason why modules shouldn't be special. Essentially, we need an<br>
> >>>> m_new() and m_init() for them. And the lifetime of the module type would<br>
> >>>> have to be linked to the (sub-)interpreter, whereas the lifetime of the<br>
> >>>> module instance would be determined by whoever uses the module and/or<br>
> >>>> decides to unload/reload it.<br>
> >>><br>
> >>> It may be simpler if the only strong reference to the module type is in<br>
> >>> the module instance itself. Successive module initializations would get<br>
> >>> different types, but that shouldn't be a problem in practice.<br>
> >><br>
> >> Agreed. Then the module instance would just be the only instance of a new<br>
> >> type that gets created each time the module initialised. Even if module<br>
> >> subtypes were to become common place once they are generally supported<br>
> >> (because they're the easiest way to store per-module state efficiently),<br>
> >> module reinitialisation should be rare enough to just buy them with a new<br>
> >> type for each. The size of the complete module state+dict will almost<br>
> >> always outweigh the size of the one additional type by factors.<br>
> ><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 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?</p>
<p dir="ltr">That's exactly what I have in mind, but the way extension module imports currently work means we can't easily do it just yet. Fortunately, importlib means we now have some hope of fixing that :)</p>
<p dir="ltr">Cheers,<br>
Nick.<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>