On Fri, Jul 3, 2009 at 17:47, Nick Coghlan <ncogh...@gmail.com> wrote:
> Tarek Ziadé wrote: > > 2009/7/3 Paul Moore <p.f.mo...@gmail.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. > > It's also very similar to the ideas that started to tick over in the > 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: > > > 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"). > > PEP 302 finders and loaders actually *are* expected to have a concept of > 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 > locations. 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. > > > Cheers, > Nick. > > 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. -Brett
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
