A plea for Python 2.3

[Jeff Squyres]

Fair enough; thanks for the detailed answer.

On May 28, 2009, at 1:56 PM, Matt Mackall wrote:

> On Wed, 2009-05-27 at 20:38 -0400, Jeff Squyres wrote:
>> I was testing the fix for http://www.selenic.com/mercurial/bts/
>> issue967 today and discovered that the next release of Mercurial will
>> not support Python 2.3.
>>
>> As a lurker on this list, I recognize that I may have missed prior
>> discussions and/or rationale for why 2.3 support is being dropped.
>> Have I missed the boat to plea for continued support for Python 2.3?
>
> I'm afraid so. We've done a fairly extensive housecleaning of 2.3ism.
> Going back to 2.3 at this point would be too much work, given that  
> we'd
> drop it before the bitter end of the RHEL4 lifecycle (2012)  
> regardless.
>
>> I ask because many of us enterprise types are using RHEL4 ("it ain't
>> broke, so they aren't fixing it") which ships with Python
>> 2.3.something.  And I will need 967 fix (support for pushing to https
>> through a proxy), which means upgrading to Mercurial <next> when it  
>> is
>> released.
>
> Well the trade-off inherent in getting seven years of stability from a
> distro is that you don't get new features.
>
> But if you're already installing Mercurial on such machines, it should
> be fairly straightforward to package a Python 2.6 install as well. The
> easiest way is to make a build Python 2.6 that installs into /usr/ 
> local/
> as python26. Then running python26 setup.py will adjust hg to use that
> Python. Then you can tar up Mercurial 1.3 and Python 2.6 in one  
> tarball
> that you unpack in /.
>
>> I, for one, might well be happy with reduced functionality with a
>> Mercurial >v1.3 running on Python 2.3.  For example, if I try "hg
>> some_cool_new_feature ...", hg may respond, "Sorry, I can't do this
>> because Python 2.3 doesn't support it.  Upgrade your Python to be  
>> able
>> to use this feature."  I don't know how feasible this is -- or if it
>> would cause unbearable ugliness in the hg code base -- but I thought
>> I'd at least throw out the idea.
>
> The biggest reason to throw out 2.3 was to throw out compatibility
> hacks. Further, no desktop operating system has had Python 2.3 for a
> while (it's not even available in the Debian 4.0, released in 2007),  
> so
> testing against 2.3 means maintaining your own Python build. We were
> regularly slipping things that broke 2.3 into the codebase because we
> were unable to test against it. There aren't any new Mercurial  
> features
> that are dependent on 2.4, it's just about maintenance overhead.
>
> -- 
> http://selenic.com : development and support for Mercurial and Linux
>
>


-- 
Jeff Squyres
Cisco Systems