<br><br><div class="gmail_quote">On Fri, Jul 3, 2009 at 17:47, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Tarek Ziadé wrote:<br>
> 2009/7/3 Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>>:<br>
>> Does this sound sensible? Tarek, would you be OK with me attempting to<br>
>> modify your prototype to support this protocol? Are there any tests<br>
>> for PEP 376, so that I can confirm I haven't completely broken<br>
>> something? If I can, I'll knock up some simple prototype importers for<br>
>> non-standard examples, and see how they work with all this.<br>
><br>
> Yes that's exactly what I was thinking about after the discussion we<br>
> had in the other<br>
> thread. This change would allow much more flexibility.<br>
<br>
</div>It's also very similar to the ideas that started to tick over in the<br>
back of my head after the previous discussion (only far more fleshed out<br>
that anything I got to - fortunately I read Paul's message before<br>
spending too much time on it!)<br>
<br>
Specifically regarding this comment from Paul:<br>
<div class="im"><br>
> Finder.uninstall(distribution_name, filter=callable, installer=name)<br>
> Uninstall the given distribution. It's likely that many finders will<br>
> be read-only. In that case, this function should return None.<br>
> Otherwise, return a list of the "files" removed. (This may need some<br>
> clarification, as many finders won't have a concept of a "file name").<br>
<br>
</div>PEP 302 finders and loaders actually *are* expected to have a concept of<br>
a "file name". For Python modules they they are expected to have it so<br>
they can populate __file__ correctly</blockquote><div><br>Not only that, lots of code out there expects values from __path__ to contain os.path.sep on top of __file__, so the idea of file paths is already hard-coded into how import works, whether we like it or not.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> (runpy is also a lot happier with<br>
them when they expose get_filename(), a relatively recent addition to<br>
the PEP 302 API).</blockquote><div><br>An addition I was not even aware of. Looks like importlib needs a little updating.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For other resources they're expected to have it so the<br>
get_data() API can work correctly.<br>
<br>
One other thing to consider: it may be desirable to have hooks for<br>
meta_path and path_hooks in distutils that are checked *before* the full<br>
import hooks in the sys module. The reason I say this is that it would<br>
allow someone to override just the metadata retrieval (e.g. to pick up<br>
the extra dependency information saved by setuptools and friends)<br>
without having to worry about breaking the actual imports from those<br>
locations.</blockquote><div><br>So as the guy who plans to try to clean up import, I just want to say that implicit finders will eventually go away. Do not start off making them implicit, but you can have them installed on sys.meta_path or sys.path_hooks by default.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Cheers,<br>
Nick.<br>
<br>
P.S. +lots on using 'metadata' in the PEP 376 method names rather than<br>
the jargon 'egginfo'. Jargon isn't always bad, but using it seems fairly<br>
gratuitous in this case.</blockquote><div><br>Ditto from here. Plus I have an aversion to terminology that goes down the reptile route instead of the Monty Python route.<br><br>-Brett <br></div></div>