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.

Suited to programmers.SE - http://programmers.stackexchange.com/ — Caffeinated, Oct 08 '11 at 00:33
Recent ipython doesn't work before 2.6, that's my biggest pain when working under SL5 (based on RHEL5). — Benjamin Bannier, Oct 08 '11 at 00:35
I hate sysadmins... they think just because something is old it's good. — JBernardo, Oct 08 '11 at 00:37

score 2 · Answer 1 · answered Oct 08 '11 at 00:37

2

What's in Which Python?

answered Oct 08 '11 at 00:37

Ned Batchelder

364,293
75
561
662

You could add `argparse` to the 2.7 (but I think it was also backported to 2.6.6). And a better `'{}'.format(syntax)` – JBernardo Oct 08 '11 at 00:41

score 2 · Accepted Answer · answered Oct 08 '11 at 07:05

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.

score 1 · Answer 3 · answered Oct 08 '11 at 00:36

1

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.

answered Oct 08 '11 at 00:36

Oscar Korz

2,457
1
18
18

Thanks for mentioning the string formatter, my project will require a lot of string manipulation, so this may be an important feature to argue fight for. – cdated Oct 08 '11 at 01:44

score 1 · Answer 4 · answered Oct 08 '11 at 02:01

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)

score 0 · Answer 5 · answered Oct 08 '11 at 00:39

0

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.

answered Oct 08 '11 at 00:39

sarnold

102,305
22
181
238

Indeed, I'm trying hard not to scoff at the older interpreter since python 2.4 is still pretty good. This project is only for internal deployment so I wont be alienating any customers, but since I'm not entirely dependent on >2.4 features maybe I shouldn't rock the boat. – cdated Oct 08 '11 at 00:47
One approach I have heard that does work well is restrict use of new features to a specific class / module / file, so they can be replaced more easily when targeting older deployments. Never tried it myself... – sarnold Oct 08 '11 at 01:04

Future Development in Python 2.4

5 Answers5