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