Re: PEP 420: Implicit Namespace Packages

On 4 May 2012 15:51, Barry Warsaw <[email protected]> wrote:
> On May 04, 2012, at 02:11 AM, [email protected] wrote:
>
>>I think it predates PEP 302 by a decade or so. You might also ask why
>>the keyword is "def", and not "define" (other than that the Grammar says
>>so). It's a natural thing, also: If the module comes from the file system,
>>it has an __file__ attribute, else it's built-in.
>
> Sure, that makes sense in a 2002 world where we didn't have importlib and all
> the modernization of the import system.  Today, it's not only antiquated, it's
> also not necessarily true.  We're already significantly overhauling the import
> machinery, so I think it's entirely reasonable to relax this constraint.

When we wrote PEP 302, so much code assumed that modules lived in the
filesystem that we had very little room for manoeuvre, One of the
goals of PEP 302 (in my mind, at least) was to disrupt the mindset
that assumed this. Now, Brett's implementation of importlib has made
that a reality - code that assumes modules live in a filesystem should
have a really good justification for doing so (and document the
limitation, ideally). I suspect you'll still break a reasonable amount
of code like this, but that's probably OK, as it's less of a breakage,
and more of a case of the existing code not anticipating cases that
never existed before.

> See my previous post for a proposal.

+1 and I'd also explicitly allow for loaders to assign other "private"
metadata as well as __file__, if only to avoid the spectre of __file__
being a base64-encoded pickled object :-)

I wonder whether treating repr specially is the best way, though -
maybe have a loader method "code_location" which is defined as being a
human-readable, but otherwise unspecified string. The key use case is
for repr, but it might be useful elsewhere (IDE tooltips or some such
usage spring to mind).

Paul.