<br><br><div class="gmail_quote">On Sun, Apr 15, 2012 at 07:26, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hooray for finally having this to the point where it has been pushed to trunk :)<br>
<div class="im"><br>
On Sun, Apr 15, 2012 at 8:16 AM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> Once again, it's just code that needs updating to run on Python 3.3 so I<br>
> don't view it as a concern. Going from list.append() to list.insert() (even<br>
> if its ``list.insert(hook, len(list)-2)``) is not exactly difficult.<br>
<br>
</div>I'm not sure you can so blithely wave away the "check this before the<br>
standard hooks" problem. If the recommended approach becomes to insert<br>
new hooks at the *start* of path_hooks and meta_path, then that should<br>
work fairly well, since the new additions will take precedence<br>
regardless of what other changes have already been made. However,<br>
trying to be clever and say "before the standard hooks, but after<br>
everything else" is fraught with peril, since there may be hooks<br>
present in the lists *after* the standard ones so naive counting<br>
wouldn't work.<br></blockquote><div><br></div><div>Well, I personally say always insert to the front of sys.meta_path because getting precedence right is always difficult when you are trying to insert into the middle of a list. I mean this issue could happen in any application that have multiple meta path finders and their is an explicit order that is desired that does not simply fall through from the way code is called.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As far as the guidelines for managing the import state go, it may be<br>
worth having public "importlib.default_path_hooks" and<br>
"importlib.default_meta_path" attributes.<br></blockquote><div><br></div><div>I don't think it is. ``importlib.default_meta_path = [importlib.machinery.PathFinder]`` and ``importlib.default_path_hooks = [importlib.machinery.some_name_I_have_not_chosen_yet, zipimport.whatever_its_called]`` is not exactly complicated and if people are not reading the docs closely enough to realize that is what the defaults are they are already asking for trouble when mucking around with import.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Then "clearing" the hooks would just be a matter of resetting them<br>
back to defaults: "sys.path_hooks[:] = importlib.default_path_hooks".<br>
You could also locate them in the hooks list correctly by checking<br>
"for i, hook in enumerate(sys.path_hooks): if hook is<br>
importlib.default_path_hooks[0]: break"<br></blockquote><div><br></div><div>You do realize people will forget the [:] and end up simply screwing up that original list, right? =)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Alternatively, it may be simpler to just expose a less granular<br>
"reset_import_hooks()" function that restores meta_path and path_hooks<br>
back to their default state (the defaults could then be private<br>
attributes rather than public ones) and invalidates all the caches.<br></blockquote><div><br></div><div>What about sys.path_importer_cache: all of it or just NullImporter/None entries (or should that be a boolean to this function)? And shouldn't it be called reset_import() with the level of changes you are proposing the function make?</div>
</div>