On Wed, Jul 15, 2009 at 06:51, Nick Coghlan
<ncoghlan@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