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

[Phillip J. Eby]

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.

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.

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.

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.