On 08/01/2008, Fred Drake <[EMAIL PROTECTED]> wrote: > On Jan 8, 2008, at 7:54 AM, J. Clifford Dyer wrote: > > Aside from the concerns of a few developers wanting simpler release > > cycles, this is definitely not the way to go. > > I don't mean that "political" (in this case, "business") reasons are > unimportant, but they can be addressed in other ways.
How? Isn't the "business" benefit of the current situation that the official installer from python.org includes (nearly) all of the basic tools required for development, without needing additional packages to be installed as well? [This is for Windows only, which is my concern - the situation for other platforms isn't something I have any experience with]. Solutions I've seen offered so far have involved easy download and installation of spun off packages (not appropriate - each separate install has a cost in terms of getting approval) or having optional "sumo" distributions, from python.org or elsewhere (not likely to be suitable, as "the official distribution" has a credibility that others don't, for better or worse). > The advantage of decoupled release cycles isn't simplicity (though > that's welcome as well, if attainable), but the ability to update > library packages independently should bug fixes be needed. Conversely, there's a risk of dilution of developer effort, and a resulting *reduction* in frequency of bug fixes. There's no clear evidence either way. > I don't think this is a huge deal for the pickle module, but is more > of an issue for some of the wrappers for external libraries. The > database packages (bsddb, sqlite) come to mind here, but aren't the > only cases where independent releases make sense. Make sense in what way? I was very happy to see sqlite included in the stdlib, as it made it part of the standard toolkit I could assume was present. There was community pressure to add it - where is the community (not developer!) pressure now to remove it? > We've certainly seen that including the "xml" package in the standard library > was questionable at best (and the tie to PyXML exacerbated that horribly). Have we? I avoid XML like the plague, but having XML support in the stdlib is certainly useful for me. The PyXML attempt to allow for an independent release cycle and/or extended functionality for a core package didn't work, certainly[1], but I don't recall anyone complaining that XML support shouldn't be in the stdlib in any form (after all, community requests for the inclusion of elementtree resulted in that being added, as well). Actually, the history so far (sqlite, elementtree, email, unittest) shows people wanting *more* in the stdlib, rather than less. Has anyone asked on somewhere like c.l.p, whether trimming the standard distribution would meet with community support? Actually, if I think about it, such a change would probably need a PEP - which should be a fun exercise for whoever writes it. So maybe the topic should be shelved until a PEP surfaces. Paul. [1] This is a good argument for rejecting the recently-raised idea of stdlib namespace packages which can easily be extended via 3rd parties. But that's about a mutable stdlib, not about what's *in* the stdlib. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
