Re: Python talks at DebConf
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 <piotr@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
Reply to: