<br><br><div class="gmail_quote">On Sat, Apr 14, 2012 at 17:12, Eric Snow <span dir="ltr">&lt;<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On Sat, Apr 14, 2012 at 2:03 PM, Brett Cannon &lt;<a href="mailto:brett@python.org">brett@python.org</a>&gt; wrote:<br>
&gt; To start off, what I am about to propose was brought up at the PyCon<br>
&gt; language summit and the whole room agreed with what I want to do here, so I<br>
&gt; honestly don&#39;t expect much of an argument (famous last words).<br>
&gt;<br>
&gt; In the &quot;ancient&quot; import.c days, a lot of import&#39;s stuff was hidden deep in<br>
&gt; the C code and in no way exposed to the user. But with importlib finishing<br>
&gt; PEP 302&#39;s phase 2 plans of getting imoprt to be properly refactored to use<br>
&gt; importers, path hooks, etc., this need no longer be the case.<br>
&gt;<br>
&gt; So what I propose to do is stop having import have any kind of implicit<br>
&gt; machinery. This means sys.meta_path gets a path finder that does the heavy<br>
&gt; lifting for import and sys.path_hooks gets a hook which provides a default<br>
&gt; finder. As of right now those two pieces of machinery are entirely implicit<br>
&gt; in importlib and can&#39;t be modified, stopped, etc.<br>
&gt;<br>
&gt; If this happens, what changes? First, more of importlib will get publicly<br>
&gt; exposed (e.g. the meta path finder would become public instead of private<br>
&gt; like it is along with everything else that is publicly exposed). Second,<br>
&gt; import itself technically becomes much simpler since it really then is about<br>
&gt; resolving module names, traversing sys.meta_path, and then handling fromlist<br>
&gt; w/ everything else coming from how the path finder and path hook work.<br>
&gt;<br>
&gt; What also changes is that sys.meta_path and sys.path_hooks cannot be blindly<br>
&gt; reset w/o blowing out import. I doubt anyone is even touching those<br>
&gt; attributes in the common case, and the few that do can easily just stop<br>
&gt; wiping out those two lists. If people really care we can do a warning in 3.3<br>
&gt; if they are found to be empty and then fall back to old semantics, but I<br>
&gt; honestly don&#39;t see this being an issue as backwards-compatibility would just<br>
&gt; require being more careful of what you delete (which I have been warning<br>
&gt; people to do for years now) which is a minor code change which falls in line<br>
&gt; with what goes along with any new Python version.<br>
&gt;<br>
&gt; And lastly, sticking None in sys.path_importer_cache would no longer mean<br>
&gt; &quot;do the implicit thing&quot; and instead would mean the same as NullImporter does<br>
&gt; now (which also means import can put None into sys.path_importer_cache<br>
&gt; instead of NullImporter): no finder is available for an entry on sys.path<br>
&gt; when None is found. Once again, I don&#39;t see anyone explicitly sticking None<br>
&gt; into sys.path_importer_cache, and if they are they can easily stick what<br>
&gt; will be the newly exposed finder in there instead. The more common case<br>
&gt; would be people wiping out all entries of NullImporter so as to have a new<br>
&gt; sys.path_hook entry take effect. That code would instead need to clear out<br>
&gt; None on top of NullImporter as well (in Python 3.2 and earlier this would<br>
&gt; just be a performance loss, not a semantic change). So this too could change<br>
&gt; in Python 3.3 as long as people update their code like they do with any<br>
&gt; other new version of Python.<br>
&gt;<br>
&gt; In summary, I want no more magic &quot;behind the curtain&quot; for Python 3.3 and<br>
&gt; import: sys.meta_path and sys.path_hooks contain what they should and if<br>
&gt; they are emptied then imports will fail and None in sys.path_importer_cache<br>
&gt; means &quot;no finder&quot; instead of &quot;use magical, implicit stuff&quot;.<br>
<br>
</div></div>This is great, Brett.  About sys.meta_path and sys.path_hooks, I see<br>
only one potential backwards-compatibility problem.<br>
<br>
Those implicit hooks were fallbacks, effectively always at the end of<br>
the list, no matter how you manipulated the them.  Code that appended<br>
onto those lists would now have to insert the importers/finders in the<br>
right way.  Otherwise the default hooks would be tried first, which<br>
has a good chance of being the wrong thing.<br>
<br>
That concern aside, I&#39;m a big +1 on your proposal.</blockquote><div><br></div><div>Once again, it&#39;s just code that needs updating to run on Python 3.3 so I don&#39;t view it as a concern. Going from list.append() to list.insert() (even if its ``list.insert(hook, len(list)-2)``) is not exactly difficult.</div>

</div>