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 eggutil.py. > 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 pkg_resources.py. 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 ;-) Cheers, -- Marc-Andre Lemburg eGenix.com 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
