increasing the python requirement

[Martin Pool]

On 5 January 2011 11:52, Gordon Tyler <gordon at doxxx.net> wrote:

>> The main thing I'm tempted by is context managers, but given that
>> bzrlib.cleanup provides an adequate alternative that works under 2.4
>> even that's not so important.
>
> I haven't seen bzrlib.cleanup so I may be talking out of my ass here,
> but `with` is probably a cleaner solution and there is a not
> insignificant benefit to clean readable code. In other words, how much
> cruft is there in the current source to satisfy python-2.4 requirements
> that could be done in a cleaner fashion under python-2.5/2.6 and make it
> much easier to understand and work with?

There's some unnecessary code due to supporting old Python's but I
think not a huge amount.  See spiv's note about grepping for mentions
of them (though this won't cover all of them.)

Cleanups are basically just

  self.addCleanup(callable)

so the lifetime is that of an object, rather than a lexical block.  In
some cases this is actually better; in others, using it is not a
burden; probably in some case with would be cleaner.

string.format <http://docs.python.org/whatsnew/2.6.html#pep-3101-advanced-string-formatting>
would be nice in 2.6 but there's not really any cruft because of
lacking it.

>> I agree with Martin that these benefits don't seem to outweigh the
>> enormous costs of backporting significant changes to a 2.4 compatible
>> version.
>
> Backporting is *nice* but is it *necessary*?

It's necessary if we add a new format and if we want to let people on
python2.4 (RHEL5) interact with branches in that format.  We don't
have work currently underway that adds a new format, but there are
things we want to do with looms/lightweight branches/etc that might
add one.

> I'm mostly playing devil's advocate here to maybe trigger some
> realization about assumptions that may have been made. I understand the
> necessity of backwards-compatibility only too well having to maintain
> JDK1.4-compatibility in my work projects (while eyeing all the nice
> stuff in JDK1.6) due to irritating customers who insist on using
> appservers that are *years* out of date. ;)

Yeah, I've been there too.  I don't think in the specific case of bzr
it is causing people much pain.

So the current bottom line of this discussion seems to be:

 * using python2.5 and 2.6 features only rates as a "would be nice"
from developers
 * dropping 2.4 support in trunk and then releasing a new format (or
something else that mandates a major upgrade) will cause pain to a
small but nontrivial subset of users
 * dropping 2.4 is not worthwhile at the moment
 * we can reconsider dropping 2.4 at the time that supporting it
becomes annoying
 * eventually we want to move to 3.x
 * do determine whether moving to 3.x requires dropping 2.4 (or 2.x
altogether) needs more study, and probably actually trying it

Therefore I think the actual actions are:

 * it's fine to run pqm on lucid (which is where this thread started)
so the main integration tests will be under python2.6
 * we should test python2.4 under Babune
 * during 2011 we should try to get at least a branch of bzr running
under python3

-- 
Martin