[Python-Dev] "setuptools has divided the Python community"

[Guido van Rossum]

On Thu, Mar 26, 2009 at 6:49 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 11:27 PM 3/26/2009 +0000, Paul Moore wrote:
>>
>> What I'd really like is essentially some form of "virtual filesystem"
>> access to stuff addressed relative to a Python package name,
>
> Note that relative to a *Python package name* isn't quite as useful, due to
> namespace packages.  To be unambiguous as to the targeted resource, one
> needs to be able to reference a specific project, and that requires you to
> go off the name of a module *within* a package.  For example,
> 'zope.somemodule' rather than just 'zope'.  To put it another way, you don't
> want to use a module that comes from an __init__.py as your origin point,
> but rather, some other .py file within the package.  Then you can talk to
> that module's loader without fear of ambiguity.

Hm, aren't you thinking of "top-level package" where I wrote
"package"? I would hope that there's always at least one level of
subpackage under a namespace package. Or we could make that a
requirement when distributing code + data files.

If it really is a common habit to have single-file modules with
associated data files directly rooted under a namespace package, we
could change the API to allow passing in a module and have it be
interpreted as "find the data as sibling files of this module." But
when given a package I would still prefer that it would look inside
the package. But to avoid ambiguities when something that's a module
in one version but a package in another I would really prefer to avoid
this.

>>  rather
>> than to a filesystem path. How much filesystem functionality is
>> required is somewhat up for debate, but the basic listdir, get
>> (text/binary) contents, open (text/binary) stream would be a good
>> start (as Guido pointed out).
>
> "isdir" and "exists" would also be nice; pkg_resources provides those, plus
> listdir and string/stream.

Yes, I forgot to re-read PEP 302 when I wrote that.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)