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.