Future Development in Python 2.4

Question

I'm starting a new python project at work that is targeted primarily at RHEL5 machines that may be upgraded to RHEL6 in couple years. Given that python 2.4 is standard on RHEL5 and the system admins won't support more than they have to, getting python 2.6 in our local repo will take some convincing. While it seems I could get by just fine with python 2.4, I feel leery about creating a project from the ground up aimed at being 100% compatible with such an old version.

Should I fight for having this project done in 2.6 or aim for the smoothest compliance with RHEL5? What are the pitfalls I should be aware of if I stick with 2.4?

FYI: I'll definitely be using sqlite, and pygtk.

Answer 1

Your best bet is probably to stick with 2.4, and have a time_machine module with all the goodies that later pythons have that you want. For example, when properties first came out you had to do something like:

def _get_prop(self):
    return self._prop
def _set_prop(self, value):
    self._prop = value
prop = property(_get_prop, _set_prop)

but in 2.6 they enhanced properties to also be decorators themselves, so then you could write:

@property
def prop(self):
    return self._prop
@prop.setter
def prop(self, value):
    self._prop = value

which means less redundant functions hanging around in your class' namespace.

I happen to like that feature a lot, so my time_machine.py has code similar to:

# 2.6+ property for 2.5-
if sys.version_info[:2] < (2, 6):
    # define our own property type
    class property():
        "2.6 properties for 2.5-"
        def __init__(self, fget=None, fset=None, fdel=None, doc=None):  ...
        def __call__(self, func):  ...
        def __get__(self, obj, objtype=None):  ...
        def __set__(self, obj, value):  ...
        def __delete__(self, obj):  ...
        def setter(self, func):  ...
        def deleter(self, func):  ...

The really nice part about this is that python equivalents are often used to demonstrate the new functionality, so you don't even have to write the code yourself.

Answer 2

What's in Which Python?

Answer 3

What's new in 2.5, 2.6, 2.7. Also, the standard library documents when certain features were added. For example, string formatting was added in 2.6. Third party library support could dodgy though.

Answer 4

My main worry would be third party libraries -- most library authors will be running 2.7 and thinking about 3.X, so any bugs that only show up with older versions are likely to get a lower priority (or ignored completely - if the bug is to do with python itself, the author could easily say it's not their library's fault)

Answer 5

Count yourself lucky -- last time I did real Python work, I had to aim for Python 1.5.2, because that was the greatest common denominator available on the RHEL systems we were targeting. Hopefully all those systems have migrated to newer tools by now.

It might feel archaic, but that's the current ecosystem: either make your software easy to deploy among your target customers or get yourself ignored. Hobbyist deployments are so much easier, they'll be running newer systems all around, but they don't often pay the bills.