On Fri, Jul 3, 2009 at 17:47, Nick Coghlan <firstname.lastname@example.org>
It's also very similar to the ideas that started to tick over in the
Tarek Ziadé wrote:
> 2009/7/3 Paul Moore <email@example.com
>> Does this sound sensible? Tarek, would you be OK with me attempting to
>> modify your prototype to support this protocol? Are there any tests
>> for PEP 376, so that I can confirm I haven't completely broken
>> something? If I can, I'll knock up some simple prototype importers for
>> non-standard examples, and see how they work with all this.
> Yes that's exactly what I was thinking about after the discussion we
> had in the other
> thread. This change would allow much more flexibility.
back of my head after the previous discussion (only far more fleshed out
that anything I got to - fortunately I read Paul's message before
spending too much time on it!)
Specifically regarding this comment from Paul:
PEP 302 finders and loaders actually *are* expected to have a concept of
> Finder.uninstall(distribution_name, filter=callable, installer=name)
> Uninstall the given distribution. It's likely that many finders will
> be read-only. In that case, this function should return None.
> Otherwise, return a list of the "files" removed. (This may need some
> clarification, as many finders won't have a concept of a "file name").
a "file name". For Python modules they they are expected to have it so
they can populate __file__ correctly
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.
(runpy is also a lot happier with
them when they expose get_filename(), a relatively recent addition to
the PEP 302 API).
An addition I was not even aware of. Looks like importlib needs a little updating.
For other resources they're expected to have it so the
get_data() API can work correctly.
One other thing to consider: it may be desirable to have hooks for
meta_path and path_hooks in distutils that are checked *before* the full
import hooks in the sys module. The reason I say this is that it would
allow someone to override just the metadata retrieval (e.g. to pick up
the extra dependency information saved by setuptools and friends)
without having to worry about breaking the actual imports from those
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.
P.S. +lots on using 'metadata' in the PEP 376 method names rather than
the jargon 'egginfo'. Jargon isn't always bad, but using it seems fairly
gratuitous in this case.
Ditto from here. Plus I have an aversion to terminology that goes down the reptile route instead of the Monty Python route.