On Thu, Jan 8, 2009 at 13:21, Nick Coghlan <ncogh...@gmail.com> wrote: > Brett Cannon wrote: >> On Thu, Jan 8, 2009 at 12:35, Nick Coghlan <ncogh...@gmail.com> wrote: >>> Brett Cannon wrote: >>>> One, does anyone have issues if I check in importlib? We have >>>> typically said code has to have been selected as best-of-breed by the >>>> community first, so I realize I am asking for a waiver on this one. >>> That rule has never really applied to things that are part of the >>> interpreter itself though (how could it?). >> >> Well, it's not part of the interpreter yet. That can be viewed as a >> separate step. > > True, but what you're doing here can be viewed as the continuation of > the original implementation plan for PEP 302 - it was always intended > that every module would eventually get a __loader__ attribute, and > that's one of the things an import system based on your importlib would > provide. >
True. I am just trying to be diplomatic and not force importlib down anyone's throats. =) >>> My main question would be how it relates to the existing import >>> machinery emulation in pkgutil. If adding importlib lets us largely drop >>> that emulation (instead replacing it with invocations of importlib), >>> then that seems like a big win to me. >> >> You mean stuff like pkgutil.ImpImporter? importlib will be fully >> modular with meta_path importers for everything short of sys.modules >> (and even that could be done if people care, but I would rather keep >> sys.modules stuff on the fast path). So there will be a meta_path >> importer that handles sys.path/sys.path_hooks/sys.path_importer_cache. >> That work is part of the "importlib is semantically done, but there >> are some things I want to imrpove" todo list. If you are more talking >> about something else I am not sure what you are after. Every module >> will have a proper loader with importlib. > > I'm talking about the fact that imp.get_loader doesn't exist, hence the > existence of pkgutil.get_loader and its supporting machinery. > Ah, OK. > My question is whether or not it is possible to replace the current > emulation code in pkgutil with appropriate imports from importlib and > thus get rid of the current semantic differences that exist between the > real import machinery and the pkgutil emulation (mainly in the area of > non-PEP 302 module loaders, such as the special case for the Windows > directory information). > Looking at pkgutil.get_loader it would not be hard to expose the same thing in importlib. Since one of the motivating factors in this is to redo the import machinery from a PEP 302 standpoint the need for pkgutil should quickly go or easily shift to importlib as needed. It's just a matter of exposing an API. -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
