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

[Glyph Lefkowitz]

On Aug 11, 2011, at 11:39 AM, Barry Warsaw wrote:

> On Aug 11, 2011, at 04:39 PM, Éric Araujo wrote:
> 
>>> * XXX what is the __file__ of a "pure virtual" package?  ``None``?
>>>  Some arbitrary string?  The path of the first directory with a
>>>  trailing separator?  No matter what we put, *some* code is
>>>  going to break, but the last choice might allow some code to
>>>  accidentally work.  Is that good or bad?
>> A pure virtual package having no source file, I think it should have no
>> __file__ at all.  I don’t know if that would break more code than using
>> an empty string for example, but it feels righter.
> 
> I agree that the empty string is the worst of the choices.  no __file__ or
> __file__=None is better.

In some sense, I agree: hacks like empty strings are likely to lead to path-manipulation bugs where the wrong file gets opened (or worse, deleted, with predictable deleterious effects).  But the whole "pure virtual" mechanism here seems to pile even more inconsistency on top of an already irritatingly inconsistent import mechanism.  I was reasonably happy with my attempt to paper over PEP 302's weirdnesses from a user perspective:

http://twistedmatrix.com/documents/11.0.0/api/twisted.python.modules.html

(or https://launchpad.net/modules if you are not a Twisted user)

Users of this API can traverse the module hierarchy with certain expectations; each module or package would have .pathEntry and .filePath attributes, each of which would refer to the appropriate place.  Of course __path__ complicates things a bit, but so it goes.

Now it seems like pure virtual packages are going to introduce a new type of special case into the hierarchy which have neither .pathEntry nor .filePath objects.

Rather than a one-by-one ad-hoc consideration of which attribute should be set to None or empty strings or "<string>" or what have you, I'd really like to see a discussion in the PEP saying what a package really is vs. what a module is, and what one can reasonably expect from it from an API and tooling perspective.  Right now I have to puzzle out the intent of the final API from the problem/solution description and thought experiment.

Despite authoring several namespace packages myself, I don't have any of the problems described in the PEP.  I just want to know how to write correct tools given this new specification.  I suspect that this PEP will be the only reference for how packages work for a long time coming (just as PEP 302 was before it) so it should really get this right.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110811/a75b8630/attachment-0001.html>