Re: Python talks at DebConf
On Tue, May 11, 2010 at 19:51, Lino Mastrodomenico
<l.mastrodomenico@gmail.com> wrote:
> 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.
Indeed, that's what we expect from the python maintainer:
- understand what changes between to major release
- prepare a draft for the transition, checking packages that brake
(reporting bugs and hopefully patches)
- get consensus from the project (release team for formal ACK on
starting the transition and from python community to support the
transition with uploads and so)
none of that has happened in the past.
> 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?
because we have a quite "original" python maintainer, that doesn't
care at all about Debian.
On the other hand, he does care (to a certain point) about Ubuntu
using the latest python version possible, of course not handling all
the problems that that version can cause.
Ah, just for the sake clarity: the Debian and Ubuntu python
maintainers are the same person.
> Are upstream programs badly written, e.g. relying on undocumented
> implementation details of a particular Python version, and their
> authors never fixed them?
Sometimes (as in abandoned softwares, that we still maintain since we
have users using them); sometimes there are package maintainer that
didn't upgrade to the latest version, so we don't have the code to
support a new version (even though the upstream authors released it)
> Is the problem using an old version of a package while the more recent
> upstream versions have already fixed the compatibility problems?
yep, sometimes, but there are also new upstream release that drop
support to a version to add support to a newer one, and we have to
support them both.
> 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?
No, I don't think those are the problems.
> I apologize if all this has already been discussed, but I hope that
no problem.
> the future transition to 2.7 and eventually to 3.x could be less
> labour-intensive than the one to 2.6.
Well, we hope several things will change on the python side of Debian;
let's see if our dreams will come true.
Regards,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Reply to: