On 18/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > Sure... though I doubt you'll have much luck, unless you drop > support for resource_filename, and stick with > resource_string()/resource_stream(). Supporting resource_filename() > for zipfiles inherently requires that you extract the file somewhere, > which is where all the jillions of lines of code for import providers > and importer registrations and egg caches and all that other stuff come in.
Yes, I intended to skip resource_filename. It's controversial at best. > By contrast, returning a resource string or stream is easy, since you > can just delegate to a __loader__ object's get_data, or fall back to > filesystem access if the importer is None. Agreed. I'm not suggesting that anything hard be added, rather that (relatively) simple things get standardised. > In Python 2.5, the pkgutil module grew a bunch of helpful APIs that > originally came from pkg_resources. In which case, the documentation wasn't updated. The 2.5 docs only mention extend_path. > (If you look at pkg_resources in > the setuptools 0.7 trunk, it actually uses these new pkgutil APIs, > instead of the bundled versions that live in the 0.6 branch.) You > should be able to use pkgutil.get_loader(modulename) to get either a > loader or None, and then look for a 'get_data' method from there. Someone should document these new functions :-( Was it you that added them? Assuming it was, what's the "simplegeneric" function doing in there? Can it be moved somewhere more sensible? I don't particularly want to use undocumented functions - even within the module that defines them. Paul. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
