Re: Python talks at DebConf
On Tue, 11.05.2010 at 00:23:55 +0200, Piotr O??arowski wrote: > [Toni Mueller, 2010-05-10] > > PS: The address "www.griffith.cc" that you mention in your .sig, does > > not resolve, and afair, Berlios is not a good project host. > > To which IP your DNS points you to? Yesterday, it didn't resolve at all, only "griffith.cc" resolved. Today it resolves like this: $ dig www.griffith.cc ... ;; ANSWER SECTION: www.griffith.cc.86400 IN CNAME vega.griffith.cc. vega.griffith.cc. 86400 IN A 92.243.19.206 ... Kind regards, --Toni++ -- 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/20100511081349.21817.qm...@oak.oeko.net
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 : > 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
Re: Python talks at DebConf
On Tue, May 11, 2010 at 19:51, Lino Mastrodomenico 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 : >> 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 -- 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/m2l8b2d7b4d100557le6090660ydae0e6a0cf097...@mail.gmail.com
Re: Python talks at DebConf
Lino, I started using Debian because I love to see a long list of packages with new upstream releases available on my hard drive every single morning. Not just 100 best known applications but every niche app./library I use. I know they are prepared by either upstream authors or people who simply use it and care about new features, not just versions. I'm not afraid to safe-upgrade them. Now that you know I'm new upstream version freak, you might understand why I'm so unhappy that Debian had 2.6 in the list of supported Python versions 1 year after Ubuntu although there was no technical reason I know of to start working on supporting 2.6 on March 2009. It hurts even more when you see how Ubuntu fails to support it and Ubuntu developers tell you that Debian developers cannot do transitions because they're slow. Why am I mentioning Ubuntu at all? Because all decisions about Python in Debian are made there. Do you still want me to answer your questions or is it clear already why I am acting as an asshole? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
