[Import-SIG] PEP 402: specification questions

[Nick Coghlan]

On Thu, Nov 10, 2011 at 8:57 AM, Barry Warsaw <barry at python.org> wrote:
> On Nov 09, 2011, at 05:13 PM, PJ Eby wrote:
>
>>In other words, the intention of PEP 402 is to have a uniform and simple
>>way to evolve packages that as a side-effect allows both traditional and
>>"namespace" packages to work.  It implements namespace packages by
>>*removing* something (i.e., getting rid of __init__.py) rather than by
>>adding something new (e.g. .pyp extensions).  For that reason, I think it's
>>better for the future of the language.
>
> That's one thing that appeals to me as a distro packager about PEP 402.  Under
> PEP 402, it seems like it would be less work to modify a set of upstream
> packages to eliminate the collisions on __init__.py.

Indeed, I don't see PEP 382 reducing the number of "Why doesn't my
'foo' package work?" questions from beginners either, since it just
replaces "add an __init__.py" with "change your directory name to
'foo.pyp'". PEP 402, by contrast, should *just work* in the most
natural way possible. Similarly, "fixing" packaging conflicts just
becomes a matter of making sure that *none* of the distro packages
involved install an __init__.py file. By contrast, PEP 382 requires
that *all* of the distro packages be updated to install to "foo.pyp"
directories instead of "foo" directories.

On the other hand, the Zen does say "Explicit is better than implicit"
and if we don't allow arbitrary files without an extension as modules,
why should we allow arbitrary directories as packages*? From that
point of view, PEP 382 is actually just bringing packages into the
same extension-based regime that we already use for distinguishing
other module types.

*This is a deliberate mischaracterisation of PEP 402, but it seems to
be a common misperception that is distorting people's reactions to the
proposal - 'marker files' actually still exist in that PEP, it's just
that their definition is "any valid Python module file or a relevant
subdirectory containing such files". If this causes problems for
Jython, then they should be able to fix it the same way CPython fixed
the DLL naming conflict problem on Windows: by *not* accepting
standard Java extensions like ".jar" and ".java" as Jython modules,
and instead requiring a Jython specific extension (e.g. ".pyj",
similar to the ".pyd" CPython uses for Windows DLLs).

While there's no reference implementation for PEP 402 that updates the
standard import machinery as yet, it's worth taking a look at Greg
Slodkowic's importlib-based implementation that came out of GSoC this
year: https://bitbucket.org/jergosh/pep-402

So yeah, I still think PEP 402 is the right answer and am -1 on PEP
382 as a result - while I think PEP 382 *is* an improvement over the
status quo, I also thing it represents an unnecessary detour relative
to where I'd like to see the import system going.

Cheers,
Nick.

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