On Wed, Jul 15, 2009 at 06:51, Nick Coghlan <ncogh...@gmail.com> wrote:
> Antoine Pitrou wrote: > > I am not sure when this discussion started. Are you replying to a 3 > month-old > > message of yours? :) > > That depends on how you define the beginning of the discussion... > Especially since I was offlist three months ago. =) > > However, the fact that importlib doesn't implement the comparatively > recent get_filename() optional extension documented in PEP 302 came up > in one of the PEP 376 threads within the last week or so. > I have been ignoring the PEP 372 discussions since I came into it late and I don't deal with packaging enough to want to influence the discussion, so I missed that point being made. > > > In any case, keeping all import-related ABCs in a single place sounds > like a > > good idea. > > Alternatively, if the method is runpy specific, it doesn't have its place > in an > > ABC, does it? > > While runpy is the only client in the standard library for the > get_filename() method, the method is still a PEP 302 extension. I > documented the extension in the PEP as loaders are the only things > reliably in a position to provide the filename details that runpy needs > to set __file__ and sys.argv[0] correctly and until importlib came along > PEP 302 itself was the only real documentation of that API. > > Since importlib is now the "go-to" location for people that want to > write their own PEP 302 importers and loaders, I would say that it is > also the right place for the new ExecutionLoader ABC. OK. I will add an ExecutionLoader ABC to importlib that simply subclasses InspectLoader and adds the get_filename() abstract method. Thanks to everyone for their feedback. -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
