Tennessee Leeuwenburg writes: > Can I ask if there's any sense in pursuing a release schedule which > is slow for whatever might be deemed the "most core modules" but > faster for "less core modules"?
I think you need to be more specific about how many levels of "fast" there should be, and why some modules might be deemed more or less "core". For example, this is part of why bsddb (sp?) was removed from the stdlib, because its cycle is different from the core (it's heavily torqued by whatever upstream chooses to throw at it, so it has been the devil to test). If you're not familiar with the history, you might try searching the list for "bsddb 'Jesus Cea' stdlib" which should bring up relevant threads. (Make sure you spell the package name right, sorry if I got it wrong!) In short, the answer is "the stuff on a different cycle is already on PyPI". > Something else which would definitely be useful for me personally > would be a kind of update egg which I could apply to, say, Python > 3.0 to bring it up to 3.1 capabilities. But this would have to be considered on a per-feature basis. If that's possible for an individual feature (ie, doesn't involve changes to the interpreter or compiler), almost surely the feature "did hard time" in PyPI. So you can probably get some version there. OTOH, such an egg would have to contain only a subset of features. If there are interdependencies between that subset and those that can't be included, in some sense you will be creating a completely new and *untested* version of Python. So I think that most server admins would really want you to restrict to features you actually need, and therefore the "best" update-egg will be very application-specific. With the new features being proposed for dist-utils, I suppose you (or anybody who feels like doing so) could create a "namespace package" for such updates, pulling in the relevant modules from PyPI. Do you think that could work for you? (See the PEP 382 threads for more info; I think current discussion has moved to distutils-SIG). _______________________________________________ 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
