Re: Let's think about removing Python 2.1 and 2.2
On 7/12/05, Kenneth Pronovici <pronovic@debian.org> wrote:
> I think you misunderstood my suggestion, and probably the suggestion of
> the OP. I did not suggest that we continue to maintain packages
> depending on these old Python versions. I just suggested that we
> continue to support the interpreters themselves, so that users can
> invoke them directly if desired.
Agreed. Note also that other implementations of the Python JVM
(Jython and Stackless) lag developments in CPython, and interested
hackers benefit greatly from having a stable binary release of CPython
against which to regression test. Could be done in a sarge chroot, of
course, or better yet in a Xen guest; but at least that's an argument
that might carry some weight with those who don't care much about
commercial users.
> This in and of itself should not be a large burden on the security team
> and should not result in very many extra packages in the archive (at
> least not hundreds extra). I can't speak for the burden on the python
> maintainers themselves, which is why I was hoping (in the part of my
> message you trimmed) that they might speak up and tell us how much of a
> burden this might be.
If you have the python-fu needed to hack on pychecker, I would guess
that they would welcome your participation. That's just a guess,
though, as I don't know them. Matthias Klose's comment that Zope is
the only reason to keep 2.3.x in the archives is a bit discouraging; I
dislike version churn for its own sake and it's a lot more painful to
migrate an app off of Windows if you have to eat upgrades to Python,
WxWidgets, etc., etc. at the same time.
The penalty for success in language design is that you accumulate an
ecosystem that's hard to drag further forward. Witness C. Square
this for weakly typed languages. Witness Perl. Square it again for
languages with multiple implementations that are way different under
the hood. Witness Scheme. Add OO snake oil (with polymorphic
operators and multiple inheritance), multithreading, and a habit of
pushing extensions down into native code for performance, and you get
a really fun and powerful language that you don't upgrade for
upgrading's sake unless you like pain or hate the poor sods in QA.
Cheers,
- Michael
Reply to: