Re: [Python-Dev] "setuptools has divided the Python community"
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.
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.
On Thu, Mar 26, 2009 at 6:49 PM, P.J. Eby <pje@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/)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 26, 2009, at 10:07 PM, Guido van Rossum wrote:
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.
Yes, it should look inside a package. Very often, a data directory will be made a package through the addition of a __init__.py just so the data can be found. There are often no other py files in such data packages. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBScxF/nEjvBPtnXfVAQJSrQP/UutsevR7ZL62snMQP++rb0lC8R7u5Uva KlZkYnro0Y9jzlld1CnAGxMtmzFHYvo7iwfQ6uHEzpDehwN+dqwxnkefTT42X5OT 3o3prDFSdIsBlQdC4JIUn5wxLfHR2LLEB3RL7RROmPfJmhM0+hzidsI0i9rBb84U B41I6O2+2jI= =aZ43 -----END PGP SIGNATURE-----
participants (3)
-
Barry Warsaw -
Guido van Rossum -
P.J. Eby