[Python-Dev] PEP 0365: Adding the pkg_resources module

M.-A. Lemburg mal at egenix.com
Mon May 21 23:44:11 CEST 2007

On 2007-05-21 22:48, Phillip J. Eby wrote:
> At 08:56 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
>> On 2007-05-21 20:01, Phillip J. Eby wrote:
>> > At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
>> >> However, since this is not egg-specific it should probably be
>> >> moved to pkgutil and get a separate PEP with detailed documentation
>> >> (the link you provided doesn't really explain the concepts, reading
>> >> the code helped a bit).
>> >
>> > That doesn't really make sense in the context of the current PEP,
>> > though, which isn't to provide a general-purpose namespace package API;
>> > it's specifically about adding an existing piece of code to the stdlib,
>> > with its API intact.
>> You seem to indicate that you're not up to discussing the concepts
>> implemented by the module and *integrating* them with the Python
>> stdlib.
> No, I'm saying something else.  I'm saying it:
> 1. has nothing to do with the PEP,
> 2. isn't something I'm volunteering to do, and
> 3. would only make sense to do as part of Python 3 stdlib
> reorganization, if it were done at all.

I don't understand that last part: how can adding a new module
or set of modules require waiting for reorganization of the
stdlib ?

All I'm suggesting is to reorganize the code in pkg_resources.py
a bit and move the relevant bits into pkgutil.py and into a new

> Now, the code is certainly under an open license, and the concepts are
> entirely free for anyone to use.  If somebody wishes to do what you're
> describing, they're certainly welcome to take on that thankless task.
> But I personally don't see the point, since by definition that new API
> would have *no current users*.  And the purpose of the PEP is to serve
> the (rather large) audience that would like to take advantage of
> existing software that uses the API.
> Thus, any proposal to alter that API faces a high entry barrier to show
> how the proposed changes would provide a signficant practical benefit to
> users.

Why is that ?

You can easily provide a pkg_resource.py module with your old API
that interfaces to the new reorganized code in the stdlib.

> That's not even remotely similar to "take it or leave it".  It might
> *seem* that way, of course, simply because in any proposal to change the
> API, there's an implicit question of why nobody proposed the change via
> the Distutils-SIG, sometime during the last 2+ years of discussions
> around that API.

This doesn't have anything to do with distutils. It's entirely
about the egg distribution format.

> I remain open-minded and curious as to the possibility that someone
> *could* propose a meaningful change, but am also rationally skeptical
> that someone actually *will* come up with something that would outweigh
> the user benefit of keeping the already published, already discussed,
> already field-tested, already in-use API.
> For that matter, I remain open-minded and curious as to the possibility
> of whether someone could propose a reasonable justification for *not*
> including the module in the stdlib.  After all, last year Fredrik Lundh
> surprised me with a convincing rationale for *not* including setuptools
> in the stdlib, which is why I backed off on doing so in 2.5, and am now
> proffering a much-reduced-in-scope proposal for 2.6.
> So, I'm perfectly willing and able to change my mind, given convincing
> reasons to do so.  So far, though, your change suggestions haven't even
> explained why *you* want them, let alone why anybody else should agree. 
> We can hardly discuss what you haven't yet said.

I'm not sure what you want to hear from me.

You asked for comments, I wrote back and gave you comments. I also
made it clear why I think that breaking up the addition into different
PEPs makes a lot of sense and why separating the code into different
modules for the same reason makes a lot of sense as well.

I also tried to stir up some discussion to make life easier
for setuptools by suggesting a user-package directory on
sys.path and adding support for namespace packages as
general Python feature instead of hiding it away in

You should see this as chance to introduce new concepts to Python.
Instead you seem to feel offended every time someone suggests a
change in your design. That's also the reason why I stopped
discussing things with you on the distutils list. There was simply
no way of getting through to you.

Perhaps we should just meet up for a beer in London sometime
and sort things out ;-)

Marc-Andre Lemburg

Professional Python Services directly from the Source  (#1, May 21 2007)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

More information about the Python-Dev mailing list