Disclaimer: I'm a Python developer, not a package maintainer, so take what I write with a grain of salt.
2010/5/10 Piotr Ożarowski <pi...@debian.org>: > Why I think derivatives should not add new versions? > * because it's mostly chasing numbers - I'm pretty sure there are not > more than 10 packages that require Python >= 2.6 and are not easy to > port to 2.5 in Ubuntu 10.04, Applications and libraries still widely supporting 2.5 doesn't necessarily mean that Python developers are happy with it and 2.6+ is not really required. In many cases it's just that there are too many end users that only have 2.5 to drop backward compatibility with it. I'm NOT complaining about the 2.5->2.6 transition, I understand that maintaining a distro with so many packages and a very high quality is extremely difficult, but keeping up with the upstream Python releases IMO it's not just "chasing numbers", see the changelogs for Python 2.6 and 2.7. A simple example: the b"foo" syntax. Apparently it's completely useless in Python 2.x, since it's equivalent to "foo". But using it in Python 2.x code makes supporting both 2.x and 3.x much easier since 2to3 can use these "annotations" to decide whether a constant should be converted to bytes or to a (unicode) string. So, yes, most programs will work with the Python version that's the default in Debian stable, but that doesn't necessarily mean that using an old version as default is harmless. It may prevent Python developers from using new features they like. And there are many (mostly minor) bugs in 2.5 fixed in 2.6 that will never be fixed in 2.5.x, similarly there are bugs in 2.6 that are only fixed in 2.7 (e.g. the infamous DeprecationWarning for md5, sha1, os.popen2, etc. in 2.6 are disabled by default in 2.7: no need to show them to the end users since these modules will never be removed from Python 2.x). [...] > or no fixes at all (>100 packages that FTBFS, ignoring broken > XS-Python-Version or debian/pyversions, packages that build > correctly, pass all tests... and do not work[1]), Why is upgrading to a new default Python so difficult, more than 19 months after 2.6 was released? Are upstream programs badly written, e.g. relying on undocumented implementation details of a particular Python version, and their authors never fixed them? Is the problem using an old version of a package while the more recent upstream versions have already fixed the compatibility problems? Are Guido & c. way too happy to break backwards compatibility without understand how many problems they are creating in the real world? Should they be warned to be much more careful? Are there old unmaintained Debian packages or patches that unnecessarily introduced incompatibilities, e.g. by hardcoding version numbers? I apologize if all this has already been discussed, but I hope that the future transition to 2.7 and eventually to 3.x could be less labour-intensive than the one to 2.6. ciao -- Lino Mastrodomenico -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin4wd9_pd_i8lo6zpqwbaw2kee6g-y7w5kb5...@mail.gmail.com
