[Python-Dev] PEP 402: Simplified Package Layout and Partitioning

[Nick Coghlan]

On Thu, Dec 1, 2011 at 1:28 AM, PJ Eby <pje at telecommunity.com> wrote:
> It doesn't help at all that I'm not really in a position to provide an
> implementation, and the persons most likely to implement have been leaning
> somewhat towards 382, or wanting to modify 402 such that it uses .pyp
> directory extensions so that PEP 395 can be supported...

While I was initially a fan of the possibilities of PEP 402, I
eventually decided that we would be trading an easy problem ("you need
an '__init__.py' marker file or a '.pyp' extension to get Python to
recognise your package directory") for a hard one ("What's your
sys.path look like? What did you mean for it to look like?"). Symlinks
(and the fact we implicitly call realname() during system
initialisation and import) just make things even messier.
*Deliberately* allowing package structures on the filesystem to become
ambiguous is a recipe for future pain (and could potentially undo a
lot of the good work done by PEP 328's elimination of implicit
relative imports).

I acknowledge there is a lot of confusion amongst novices as to how
packages and imports actually work, but my diagnosis of the root cause
of that problem is completely different from that supposed by PEP 402
(as documented in the more recent versions of PEP 395, I've come to
believe it is due to the way we stuff up the default sys.path[0]
initialisation when packages are involved).

So, in the end, I've come to strongly prefer the PEP 382 approach. The
principle of "Explicit is better than implicit" applies to package
detection on the filesystem just as much as it does to any other kind
of API design, and it really isn't that different from the way we
treat actual Python files (i.e. you can *execute* arbitrary files, but
they need to have an appropriate extension if you want to import
them).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia