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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
