[Import-SIG] PEP 402: specification questions

[PJ Eby]

On Wed, Nov 9, 2011 at 3:49 PM, "Martin v. Löwis" <martin at v.loewis.de>wrote:

> ISTM that the two PEPs give opposing answers to some questions,
> which ultimately requires somebody to make a decision. I'm not sure
> which of these differences you consider fundamental, and which
> arbitrary. To give some examples:
> - what constitutes a package on disk?
> - what's the impact of this new feature on existing P/__init__.py
>  packages?
> - what's the impact on existing modules P.py?
> - when exactly is the path scan performed?
>
> It might also be that you worked on PEP 402 only because PEP 382
> appeared stalled (which it was for some time).


If you review the Import-SIG traffic from that time period, you'll notice
that I first attempted to revise PEP 382 to address various issues --
mostly having to do with clarity and ease of backported implementations for
2.x.  As the work went on, it eventually became clear that the reason the
terminology was complicated and the spec difficult to clarify (not just for
me but for other import-sig participants) was because Python's fundamental
notion of packages was flawed, and that what Guido previously tried to do
with getting rid of the need for __init__.py (see the references in PEP
402) was a more Pythonic approach (as well as being more familiar to users
of other languages).

So, the goal for 402 was to make __init__.py ("self-contained" packages)
the special case, rather than namespace packages, and achieve a more
natural fit and ease overall.

The use of .pyp extensions doesn't really fit well with that approach,
though.  It means, for example, that you have to use ugly paths (e.g.
zope.pyp/interface.pyp/foo.py), and you have a less orthogonal path for
switching between package types.

That is, under 402, you can make a module a package just by adding a
directory.  And you can make a self-contained package into an open package
(or vice versa) by adding or deleting packagename/__init__.py or moving it
to packagename.py.

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.



> If you are happy
> with PEP 382 in its current form, you might want to withdraw PEP 402.
>

Not really.  I think that PEP 402 is approximately how Python packages
should have worked all along, and that this is a good opportunity to
rectify the current situation.  While some projects may run into issues
with files becoming importable that previously weren't, any code that was
trying to import those modules is already broken.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20111109/b2583915/attachment.html>