Re: [Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)
At 09:43 AM 3/19/2008 +0000, Paul Moore wrote:
On 19/03/2008, Phillip J. Eby
wrote: I don't particularly want to use undocumented functions - even within the module that defines them.
Er, you could always document them, you know. I just didn't get around to it before the whole "setuptools flap of 2005" wiped out my motivation to do any further work on Python 2.5. For the most part, they do have docstrings. I just never did the LaTeX work on them. And now, you can use reST instead of LaTeX. :)
I could, but the problem is I don't really follow the code. My motivation is to add useful functions, not document stuff that's already there. You mentioned using get_loader to implement resource_string. OK, but I'd have done something a lot simpler than the code of get_loader, and I don't understand why the code in there is necessary.
It's so that you can get loaders for modules that aren't imported yet -- and your code would need to handle this case too. (You could handle it by actually going ahead and importing the module, as pkg_resources does, but there are other tools using pkgutil to e.g. inspect as-yet-unimported modules.)
Never mind, I'll implement what I'm planning on using my own code, and ignore trying to understand the (corner cases of the) undocumented functions.
You don't really need to, because even though they're technically "undocumented", the intent was for them to be published APIs (apart from simplegeneric, which is an implementation detail). The docs just never got copied to the official docs. These APIs are also actively used by at least pydoc and pyrun in Python 2.5, so they're unlikely to go away or break.
On 19/03/2008, Phillip J. Eby
It's so that you can get loaders for modules that aren't imported yet -- and your code would need to handle this case too.
Well, technically, it need not, as I don't *need* to implement the exact functionality that pkg_resources does. My (personal) goal is to standardise the functionality, not to cater for every possible use case.
(You could handle it by actually going ahead and importing the module, as pkg_resources does, but there are other tools using pkgutil to e.g. inspect as-yet-unimported modules.)
I'm not sure what you mean by that. There are no tools using pkgutil.resource_stream, as it doesn't exist yet. So whether it imports the module or not cannot be relevant (although it should be documented).
You don't really need to, because even though they're technically "undocumented", the intent was for them to be published APIs (apart from simplegeneric, which is an implementation detail). The docs just never got copied to the official docs.
If it's just a matter of copying documentation from the PkgResources page, that's no issue. However, only get_importer is documented on the PkgResources page. On reviewing the pkg_resources APIs, I only see the following that look worth porting to pkgutil: * resource_exists(package, resource_name) * resource_stream(package, resource_name) * resource_string(package, resource_name) * resource_isdir(package, resource_name) * resource_listdir(package, resource_name) For all of these, the first argument would be restricted to a package/module name. The option of specifying a "requirement" is not suitable. Also, automatic extraction and resource_filename is far beyond what I see as sensible in the stdlib. Hmm, these go way beyond the simple (and optional) loader.get_data interface from PEP 302. And yet the pkg_resources machinery is far more complex than I'd want to see in the stdlib. Maybe I'll just reinvent the wheel and see how far I get :-) Paul.
participants (2)
-
Paul Moore
-
Phillip J. Eby