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

Reply via email to