Antoine Pitrou wrote:
This sounds like a bad idea to me. Each Python release is tested and debugged as
a whole. If you have a lot of possible combinations (module A version 1.1 with
module B version 1.2, etc.), it becomes impossible for us to ensure proper QA
for the whole and as a result the quality might become lower, rather than
higher.
I'd certainly still see there being "blessed" python releases.
(The Zope community does this in the form of "known good sets" and
these, for me, would be "the python releases")
However, it's pretty frustrating to not be able to upgrade a pure-python
package with a critical bug (as happened recently to me with httplib)
because it's part of the stdlib.
It's also frustrating to have to if-then-else about a package or
project's dependencies when using dependency management tools like
buildout when libraries such as elementtree and argparse become part of
the stdlib when they weren't before...
(of course, if we rigorously enforce APIs and preserve compatibility, this might
not be a real issue; but our compatibility story is a bit irregular, IMHO)
Breaking it apart like this would *make* the compatibility story better...
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
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
