<p>On Nov 13, 2011 3:21 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> On Sun, Nov 13, 2011 at 6:28 PM, "Martin v. Löwis" <<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>> wrote:<br>
> > Am 13.11.2011 06:12, schrieb Nick Coghlan:<br>
> >> I finally got around to updating the import engine draft PEP and<br>
> >> publishing it on <a href="http://python.org">python.org</a>: <a href="http://www.python.org/dev/peps/pep-0406/">http://www.python.org/dev/peps/pep-0406/</a><br>
> ><br>
> > I think the rationale section needs to be improved. In fact, I still<br>
> > don't understand what the objective of this API is (I do understand what<br>
> > it achieves, but it's unclear why having that is desirable, and for what<br>
> > applications).<br>
><br>
> It's desirable for the same reason *any* form of object-oriented<br>
> encapsulation is desirable: because it makes it easier to *think*<br>
> about the problem and manage interdependencies between state updates.<br>
> I didn't realise the merits of OO designs needed to be justified - I<br>
> figured the list of 6 pieces of interdependent process global state<br>
> spoke for itself.<br>
><br>
> > I notice that there is overlap both with multiple subinterpreters,<br>
> > and with restricted execution. It hints at providing both, but actually<br>
> > provides neither.<br>
><br>
> It doesn't claim to provide either - it's sole aim is to provide a<br>
> relatively lightweight mechanism to selectively adjust elements of the<br>
> import system (e.g. adding to sys.path when importing plugins, but<br>
> leaving it alone otherwise).<br>
><br>
> But having the import state better encapsulated would make it easier<br>
> to improve the isolation of subinterpreters so that they aren't<br>
> sharing Python modules, even if they still share extension modules<br>
> (you could put a single pointer to the import engine on the<br>
> interpreter state rather than storing it in sys the way we do now).<br>
><br>
> > I think the long-term solution really should be proper support for<br>
> > subinterpreters, where there is no global state in C at all. Extension<br>
> > modules already can achieve this through the PEP 3121 API (even though<br>
> > few modules actually do).<br>
> ><br>
> > If the objective is to have more of the import machinery implemented in<br>
> > Python, then making importlib the import machinery might be best.<br>
><br>
> Guido already approved (in principle) that change - this PEP would<br>
> actually depend on that being done first (because I think trying to<br>
> build this API directly on top of import.c would be a complete waste<br>
> of time).<br>
><br>
> > If the objective is to allow hooks into the import procedure, it would<br>
> > be best to just provide the hooks. OTOH, PEP 302 already defined hooks,<br>
> > and it seems that people are happy with these.<br>
><br>
> No, they're not. Yes, the hooks are *usable*, but they're damn hard to<br>
> comprehend. When even the *experts* hate messing with a subsystem,<br>
> it's a hint that there's something wrong with the way it is set up.</p>
<p>This is the big motivator for my talk proposal at the next PyCon, on getting the most out of Python imports. They're woefully under-utilized IMHO, exactly because the import machinery is generally poorly understood.</p>
<p>-eric<br></p>
<p>> In<br>
> this case, I firmly believe a big part of the problem is that the<br>
> import system is a complex, interdependent mechanism, but there's no<br>
> coherence to the architecture. It's as if the whole thing was written<br>
> in C from an architectural point of view, but without even bothering<br>
> to create a dedicated structure to hold the state.<br>
><br>
> Cheers,<br>
> Nick.<br>
><br>
> --<br>
> Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
> _______________________________________________<br>
> Import-SIG mailing list<br>
> <a href="mailto:Import-SIG@python.org">Import-SIG@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/import-sig">http://mail.python.org/mailman/listinfo/import-sig</a><br>
</p>