At 09:01 PM 3/18/2008 +0000, Paul Moore wrote: >On 18/03/2008, Marius Gedminas <[EMAIL PROTECTED]> wrote: > > +1 for something like this in the stdlib. > > > > os.path.join(os.path.dirname(__file__), 'foo') just has too many > > problems. > >Hmm, maybe I should put some of my money where my mouth is. I'd be >willing to work up a patch to add some key items into the pkgutils >module. However, I don't like the thought of reinventing the wheel - >Phillip, would you be OK with me stealing code where I can from >pkg_resources?
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. 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. In Python 2.5, the pkgutil module grew a bunch of helpful APIs that originally came from pkg_resources. (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. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig