Fwd: Anyone still using Python 2.5?
What's the python-dev view on this? -------- Original Message -------- Subject: Anyone still using Python 2.5? Date: Wed, 21 Dec 2011 07:15:46 +0000 From: Chris Withers <chris@simplistix.co.uk> To: Python List <python-list@python.org>, "testing-in-python@lists.idyll.org" <testing-in-python@lists.idyll.org>, simplistix@googlegroups.com Hi All, What's the general consensus on supporting Python 2.5 nowadays? Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays? I'm finally getting some continuous integration set up for my packages and it's highlighting some 2.5 compatibility issues. I'm wondering whether to fix those (lots of ugly "from __future__ import with_statement" everywhere) or just to drop Python 2.5 support. What do people feel? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Wed, Dec 21, 2011 at 08:16, Chris Withers <chris@simplistix.co.uk> wrote:
This seems rather off-topic for python-dev. FWIW, on Gentoo we're just now getting to dropping 2.4, so we'll support 2.5 quite a bit longer. That's also the tendency I see from the ecosystem, at least insofar as I notice. On the other hand, we've had 2.7 as the default python on our stable branch since March 2011. I also know Mercurial is still supporting 2.4 (they tend to be conservative about dropping support for old releases). Cheers, Dirkjan
On Wed, Dec 21, 2011 at 07:16:06AM +0000, Chris Withers wrote:
What's the general consensus on supporting Python 2.5 nowadays?
Do people still have to use this in commercial environments
I have to use it. There is a rather large and complex intranet site with both 32- and 64-bit versions of Python and libraries, and there are about 70 copies of it at client sites so it'd be very hard to recompile and adapt it to Python 2.6, test and upgrade all clients. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Dec 21, 2011, at 07:16 AM, Chris Withers wrote:
What's the general consensus on supporting Python 2.5 nowadays?
FWIW, Ubuntu dropped 2.5 quite a while ago. The next LTS (long term support) release in April 2012 will have only Python 2.7 (and 3.2). The currently in-development next Debian release currently has only Python 2.6, 2.7, and 3.2 with 2.7 as the default. For my own code, Python 2.6 is the minimum, and I'm seeing more upstream libraries target 2.6 as a minimum also (e.g. dbus-python). When projects say they still need to target older Pythons, RHEL support is usually cited as the reason. Cheers, -Barry
On 21 Dec 2011, at 12:42, Barry Warsaw wrote:
For "production work" I've been on 2.6 for a while and will soon be switching to 2.7 (I do my development on 2.7). For my libraries I'm still supporting 2.4. The *major* syntax feature you lose by targeting 2.4 is the with statement, so it will be nice to drop 2.4 support. The next releases of mock and unittest2 will still support 2.4, but the ones after that will be 2.5+. Thankfully tox makes testing across multiple versions (and implementations) easy. All the best, Michael Foord
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
Michael Foord <fuzzyman@voidspace.org.uk> wrote:
True, but 2.5 is still current on Hardy, an LTS release that is officially supported until April 2013. Lots of places still use 2.5 on Hardy (or on Lucid, the LTS release after Hardy, though they have to get it from the deadsnakes repository as its not the normal version on Lucid). My workplace uses 2.5 for a lot of things, but is slowly transitioning to 2.6.
My own personal software generally tries to stay compatible further back. getmail is used on lots of little network appliances and such that don't necessarily run a current OS, so getmail v4 targets 2.3.3 and up. If I'm writing something new today, I usually assume 2.6 and up. Charles -- ----------------------------------------------------------------------- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ -----------------------------------------------------------------------
On Wed, 2011-12-21 at 07:42 -0500, Barry Warsaw wrote:
Some servers I deploy to run Ubuntu, but we're installing previous python versions to support our apps - OS support isn't a factor in which version we develop for. I work on applications in 2.4-2.6. Generally: 2.4 apps are legacy and a migration is planned in the next year (either to 2.7 or to pypy). 2.5 apps are the speed-critical ones. Our tests showed the performance was different enough between 2.5 and 2.6 for me to not update. They also have significant native extensions in them so are potentially the most difficult to port to python3. 2.6 apps are newish and (mainly) pure python. I can see myself still using 2.5 for many years, but porting the 2.6 and 2.4 code to either pypy or python3 in the not too distant future. I believe we're most likely to choose python3 for apps with heavy use of Unicode (and pick a version after the changes to internal unicode format landed). Tim Wintle
On Thu, 22 Dec 2011 09:44:32 +0000 Tim Wintle <timwintle@gmail.com> wrote:
2.5 apps are the speed-critical ones. Our tests showed the performance was different enough between 2.5 and 2.6 for me to not update.
Really? Where's the regression? Regards Antoine.
Antoine Pitrou, 22.12.2011 10:56:
That's not unexpected at least, and matches my own (limited) experience here. My gut feeling is that Py2.6 added a lot of "new in Py3.0" overhead, but without all the optimisations that went into Py3.x since then. At least some of that came back later with Py2.7. Would be nice to (eventually) see Py2.[567] run in speed.python.org in order to get a better idea of the relative performance. Stefan
On Thu, 2011-12-22 at 10:56 +0100, Antoine Pitrou wrote:
I'm not certain - IIRC there were several nice optimisations in 2.6, and I wasn't expecting that when I first looked. I was running code designed for 2.5 under 2.6, so it's likely that with sufficient tweaking for 2.6 I might not have the same result. I tested this specific code with the python builds we have in production, not general python code - I don't mean this as a recommendation that anyone else assume 2.5 is faster for them. I suspect that Stefan's comments about newly added features without the optimisation in python3 might be partially true, but having the extra code to support them (while not using them) might also be part of the cause - ceval.c had over 1K line changes between r25 and r26, including cases for new opcodes, and new opcode predictions etc - it's possible that my code just happens to not follow the most optimal paths. I'm talking about a slow-down of under 10%, but enough that I couldn't justify moving these apps to 2.6 at the time for economic reasons, and pypy would be the main incentive to move this to 2.7. Tim
On Wed, Dec 21, 2011 at 07:42:45AM -0500, Barry Warsaw wrote:
FWIW, Ubuntu dropped 2.5 quite a while ago. The next LTS (long term support)
That's true for *CURRENT* releases, however Ubuntu still supports Python 2.5 via 8.04 LTS (end of life in April 2013). Lucid is 2.6 and goes EOL in 2015. Red Hat Enterprise is a bit more difficult a situation. They currently still have active support for Python 2.3 in RHEL 4, but that comes up to EOL in just a couple of months (Feb 2012). But they have this "extended life cycle" that ends in Feb 2015. RHEL 5 has python 2.4.3 and has an EOL of April 2014 (April 2017 for extended life cycle). There was a fairly large lag between RHEL 5 and RHEL 6 (almost 4 years), so there are a *LOT* of RHEL 5 systems out there. RHEL 6 has Python 2.6.6, BTW. This is why I recently released the "ineedpy2" package so that your program can request and search for specific versions of Python on a multi-python system. We have a number of systems that have Python 2.3 and older on them, but many of those systems have newer Pythons also available as alternate names. We recommend that whenever possible customers target deploying against the system python, meaning version 2.4.3 if they are deploying on CentOS 5. Because otherwise security updates of Python and *all the libraries they depend on* need to be tracked manually. Some customers decide to go one route, some to go the other, but that is our recommendation. Ideally, you are building your apps to target a production environment, not just using the latest and greatest Python without compelling reasons. So, yes, people are still using Python 2.5 and 2.4. Mostly this is people who have already deployed apps and are either fixing/updating them, or are adding new applications that they want to target the same production environment rather than setting up a new environment. Sean -- Linux, because eventually you grow up enough to be trusted with a fork(). Sean Reifschneider, Member of Technical Staff <jafo@tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
On Wed, 21 Dec 2011 07:16:06 +0000 Chris Withers <chris@simplistix.co.uk> wrote:
What's the python-dev view on this?
Python 2.5 is not supported by *us* anymore (*). Anyone still using it therefore relies on their OS vendor to apply potential security patches and other important fixes. Library authors can of course choose to still support it. I wouldn't care personally. I'm of the opinion that people who (by their choice of OS) have a preference for legacy software shouldn't ask for the latest versions of Python libraries. (*) From http://www.python.org/download/releases/2.5.6/ : “This release is the final release of Python 2.5; under the current release policy, no security issues in Python 2.5 will be fixed anymore.” Regards Antoine.
On 21/12/2011 15:26, anatoly techtonik wrote:
App engine 1.6 improved support of Python 2.7, so I hope that -slowly- everybody will move to Python 3. Oops, I mean Python 2.7 ;-) http://code.google.com/appengine/docs/python/python27/ Victor
On Thu, Dec 22, 2011 at 4:55 AM, Victor Stinner < victor.stinner@haypocalc.com> wrote:
I've just got reminded that Python 2.7 support in AppEngine is still experimental, so the exodus is unlikely to happen soon. https://groups.google.com/forum/#!topic/google-appengine-python/tPbDEAHke64
FWIW, the most recent version of pywin32 has the following download counts (rounded to the nearest thousand) Version 32bit 64bit ------------------------- 3.2 - 75,000 9,000 3.1 - 4,000 1,000 2.7 - 126,000 16,000 2.6 - 46,000 6,000 2.5 - 21,000 n/a 2.4 - 3,000 n/a 2.3 - 1,000 n/a So ISTM that 2.5 isn't hugely popular these days, but also isn't insignificant. It probably means I could "safely" drop 2.3 and 2.4 support though... Mark On 21/12/2011 6:16 PM, Chris Withers wrote:
On 22 Dec 2011, at 01:25, Mark Hammond wrote:
These figures can't possibly be true. No-one is using Python 3 yet. ;-) FWIW I heard a few days ago about a UK government department, HMGCC (Her Majesty's Government Communication Centre - based in Milton Keynes), who use Python for research projects. They switched to using Python 3 a while ago. All the best, Michael Foord
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On Thu, 22 Dec 2011 01:49:37 +0000 Michael Foord <fuzzyman@voidspace.org.uk> wrote:
These figures can't possibly be true. No-one is using Python 3 yet. ;-)
Since you brought it up. Is anyone paying people (or trying to hire people) to write Python 3? Thanks, <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On Thu, Dec 22, 2011 at 4:49 AM, Michael Foord <fuzzyman@voidspace.org.uk>wrote:
python.org should have a poll/settings for active python.org accounts to allow people mark when they switch to Python 3. FWIW I heard a few days ago about a UK government department, HMGCC (Her
if that == True: front_page.response(news_template.render("News About Her Majesty switched to Python 3")) Can't stand to do a +1 for the news item. All the best,
Michael Foord
What's the general consensus on supporting Python 2.5 nowadays?
There is no such consensus :-)
Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays?
At work, we are still using Python 2.5. Six months ago, we started a project to upgrade to 2.7, but we have now more urgent tasks, so the upgrade is delayed to later. Even if we upgrade new clients to 2.7, we will have to continue to support 2.5 for some more months (or years?). In a personal project (the IPy library), I dropped support of Python 2.5 in february 2011. Recently, I got a mail asking me where the previous version of my library (supporting Python 2.4) can be downloaded! Someone is still using Python 2.4: "I'm stuck with python 2.4 in my work environment."
What do people feel?
For a new project, try to support Python 2.5, especially if you would like to write a portable library. For a new application working on Mac OS X, Windows and Linux, you can only support Python 2.6. Victor
On Thu, Dec 22, 2011 at 02:49:06AM +0100, Victor Stinner wrote:
At my work, I'm on RHEL5 and RHEL6. So I'm currently supporting python-2.4 and python-2.6. We're up to 75% RHEL6 (though, not the machines where most of our deployed, custom written apps are running) so I shouldn't have to support python-2.4 for much longer.
As part of work, I package for EPEL5 (addon packages for RHEL5). Sometimes we need a new version of a package or a new package for RHEL5 and thus need to have python-2.4 compatible versions of the package and any of its dependencies. When I no longer need to maintain python-2.4 stuff for work, I'm hoping to not have to do quite so much of this but sometimes I know I'll still get requests to update an existing package to fix a bug or fix a feature and that will require updates of dependent libraries. I'll still be stuck looking for python-2.4 compatible versions of all of these :-(
I agree that libraries have a need to go farther back than applications. I have one library that I support on python-2.3 (for RHEL4... I'm counting down the months on that one :-). Every other library I maintain, I make sure I support at least python-2.4. Application-wise, I currently have to support python-2.4+ but given that Linux distros seem to all have some version out that supports at least python-2.6, I don't think I'll be developing any applications that intentionally support less than that once I get moved away from RHEL-5 at my workplace. -Toshio
On Wed, Dec 21, 2011 at 08:16, Chris Withers <chris@simplistix.co.uk> wrote:
This seems rather off-topic for python-dev. FWIW, on Gentoo we're just now getting to dropping 2.4, so we'll support 2.5 quite a bit longer. That's also the tendency I see from the ecosystem, at least insofar as I notice. On the other hand, we've had 2.7 as the default python on our stable branch since March 2011. I also know Mercurial is still supporting 2.4 (they tend to be conservative about dropping support for old releases). Cheers, Dirkjan
On Wed, Dec 21, 2011 at 07:16:06AM +0000, Chris Withers wrote:
What's the general consensus on supporting Python 2.5 nowadays?
Do people still have to use this in commercial environments
I have to use it. There is a rather large and complex intranet site with both 32- and 64-bit versions of Python and libraries, and there are about 70 copies of it at client sites so it'd be very hard to recompile and adapt it to Python 2.6, test and upgrade all clients. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Dec 21, 2011, at 07:16 AM, Chris Withers wrote:
What's the general consensus on supporting Python 2.5 nowadays?
FWIW, Ubuntu dropped 2.5 quite a while ago. The next LTS (long term support) release in April 2012 will have only Python 2.7 (and 3.2). The currently in-development next Debian release currently has only Python 2.6, 2.7, and 3.2 with 2.7 as the default. For my own code, Python 2.6 is the minimum, and I'm seeing more upstream libraries target 2.6 as a minimum also (e.g. dbus-python). When projects say they still need to target older Pythons, RHEL support is usually cited as the reason. Cheers, -Barry
On 21 Dec 2011, at 12:42, Barry Warsaw wrote:
For "production work" I've been on 2.6 for a while and will soon be switching to 2.7 (I do my development on 2.7). For my libraries I'm still supporting 2.4. The *major* syntax feature you lose by targeting 2.4 is the with statement, so it will be nice to drop 2.4 support. The next releases of mock and unittest2 will still support 2.4, but the ones after that will be 2.5+. Thankfully tox makes testing across multiple versions (and implementations) easy. All the best, Michael Foord
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
Michael Foord <fuzzyman@voidspace.org.uk> wrote:
True, but 2.5 is still current on Hardy, an LTS release that is officially supported until April 2013. Lots of places still use 2.5 on Hardy (or on Lucid, the LTS release after Hardy, though they have to get it from the deadsnakes repository as its not the normal version on Lucid). My workplace uses 2.5 for a lot of things, but is slowly transitioning to 2.6.
My own personal software generally tries to stay compatible further back. getmail is used on lots of little network appliances and such that don't necessarily run a current OS, so getmail v4 targets 2.3.3 and up. If I'm writing something new today, I usually assume 2.6 and up. Charles -- ----------------------------------------------------------------------- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ -----------------------------------------------------------------------
On Wed, 2011-12-21 at 07:42 -0500, Barry Warsaw wrote:
Some servers I deploy to run Ubuntu, but we're installing previous python versions to support our apps - OS support isn't a factor in which version we develop for. I work on applications in 2.4-2.6. Generally: 2.4 apps are legacy and a migration is planned in the next year (either to 2.7 or to pypy). 2.5 apps are the speed-critical ones. Our tests showed the performance was different enough between 2.5 and 2.6 for me to not update. They also have significant native extensions in them so are potentially the most difficult to port to python3. 2.6 apps are newish and (mainly) pure python. I can see myself still using 2.5 for many years, but porting the 2.6 and 2.4 code to either pypy or python3 in the not too distant future. I believe we're most likely to choose python3 for apps with heavy use of Unicode (and pick a version after the changes to internal unicode format landed). Tim Wintle
On Thu, 22 Dec 2011 09:44:32 +0000 Tim Wintle <timwintle@gmail.com> wrote:
2.5 apps are the speed-critical ones. Our tests showed the performance was different enough between 2.5 and 2.6 for me to not update.
Really? Where's the regression? Regards Antoine.
Antoine Pitrou, 22.12.2011 10:56:
That's not unexpected at least, and matches my own (limited) experience here. My gut feeling is that Py2.6 added a lot of "new in Py3.0" overhead, but without all the optimisations that went into Py3.x since then. At least some of that came back later with Py2.7. Would be nice to (eventually) see Py2.[567] run in speed.python.org in order to get a better idea of the relative performance. Stefan
On Thu, 2011-12-22 at 10:56 +0100, Antoine Pitrou wrote:
I'm not certain - IIRC there were several nice optimisations in 2.6, and I wasn't expecting that when I first looked. I was running code designed for 2.5 under 2.6, so it's likely that with sufficient tweaking for 2.6 I might not have the same result. I tested this specific code with the python builds we have in production, not general python code - I don't mean this as a recommendation that anyone else assume 2.5 is faster for them. I suspect that Stefan's comments about newly added features without the optimisation in python3 might be partially true, but having the extra code to support them (while not using them) might also be part of the cause - ceval.c had over 1K line changes between r25 and r26, including cases for new opcodes, and new opcode predictions etc - it's possible that my code just happens to not follow the most optimal paths. I'm talking about a slow-down of under 10%, but enough that I couldn't justify moving these apps to 2.6 at the time for economic reasons, and pypy would be the main incentive to move this to 2.7. Tim
On Wed, Dec 21, 2011 at 07:42:45AM -0500, Barry Warsaw wrote:
FWIW, Ubuntu dropped 2.5 quite a while ago. The next LTS (long term support)
That's true for *CURRENT* releases, however Ubuntu still supports Python 2.5 via 8.04 LTS (end of life in April 2013). Lucid is 2.6 and goes EOL in 2015. Red Hat Enterprise is a bit more difficult a situation. They currently still have active support for Python 2.3 in RHEL 4, but that comes up to EOL in just a couple of months (Feb 2012). But they have this "extended life cycle" that ends in Feb 2015. RHEL 5 has python 2.4.3 and has an EOL of April 2014 (April 2017 for extended life cycle). There was a fairly large lag between RHEL 5 and RHEL 6 (almost 4 years), so there are a *LOT* of RHEL 5 systems out there. RHEL 6 has Python 2.6.6, BTW. This is why I recently released the "ineedpy2" package so that your program can request and search for specific versions of Python on a multi-python system. We have a number of systems that have Python 2.3 and older on them, but many of those systems have newer Pythons also available as alternate names. We recommend that whenever possible customers target deploying against the system python, meaning version 2.4.3 if they are deploying on CentOS 5. Because otherwise security updates of Python and *all the libraries they depend on* need to be tracked manually. Some customers decide to go one route, some to go the other, but that is our recommendation. Ideally, you are building your apps to target a production environment, not just using the latest and greatest Python without compelling reasons. So, yes, people are still using Python 2.5 and 2.4. Mostly this is people who have already deployed apps and are either fixing/updating them, or are adding new applications that they want to target the same production environment rather than setting up a new environment. Sean -- Linux, because eventually you grow up enough to be trusted with a fork(). Sean Reifschneider, Member of Technical Staff <jafo@tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
On Wed, 21 Dec 2011 07:16:06 +0000 Chris Withers <chris@simplistix.co.uk> wrote:
What's the python-dev view on this?
Python 2.5 is not supported by *us* anymore (*). Anyone still using it therefore relies on their OS vendor to apply potential security patches and other important fixes. Library authors can of course choose to still support it. I wouldn't care personally. I'm of the opinion that people who (by their choice of OS) have a preference for legacy software shouldn't ask for the latest versions of Python libraries. (*) From http://www.python.org/download/releases/2.5.6/ : “This release is the final release of Python 2.5; under the current release policy, no security issues in Python 2.5 will be fixed anymore.” Regards Antoine.
On 21/12/2011 15:26, anatoly techtonik wrote:
App engine 1.6 improved support of Python 2.7, so I hope that -slowly- everybody will move to Python 3. Oops, I mean Python 2.7 ;-) http://code.google.com/appengine/docs/python/python27/ Victor
On Thu, Dec 22, 2011 at 4:55 AM, Victor Stinner < victor.stinner@haypocalc.com> wrote:
I've just got reminded that Python 2.7 support in AppEngine is still experimental, so the exodus is unlikely to happen soon. https://groups.google.com/forum/#!topic/google-appengine-python/tPbDEAHke64
FWIW, the most recent version of pywin32 has the following download counts (rounded to the nearest thousand) Version 32bit 64bit ------------------------- 3.2 - 75,000 9,000 3.1 - 4,000 1,000 2.7 - 126,000 16,000 2.6 - 46,000 6,000 2.5 - 21,000 n/a 2.4 - 3,000 n/a 2.3 - 1,000 n/a So ISTM that 2.5 isn't hugely popular these days, but also isn't insignificant. It probably means I could "safely" drop 2.3 and 2.4 support though... Mark On 21/12/2011 6:16 PM, Chris Withers wrote:
On 22 Dec 2011, at 01:25, Mark Hammond wrote:
These figures can't possibly be true. No-one is using Python 3 yet. ;-) FWIW I heard a few days ago about a UK government department, HMGCC (Her Majesty's Government Communication Centre - based in Milton Keynes), who use Python for research projects. They switched to using Python 3 a while ago. All the best, Michael Foord
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On Thu, 22 Dec 2011 01:49:37 +0000 Michael Foord <fuzzyman@voidspace.org.uk> wrote:
These figures can't possibly be true. No-one is using Python 3 yet. ;-)
Since you brought it up. Is anyone paying people (or trying to hire people) to write Python 3? Thanks, <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On Thu, Dec 22, 2011 at 4:49 AM, Michael Foord <fuzzyman@voidspace.org.uk>wrote:
python.org should have a poll/settings for active python.org accounts to allow people mark when they switch to Python 3. FWIW I heard a few days ago about a UK government department, HMGCC (Her
if that == True: front_page.response(news_template.render("News About Her Majesty switched to Python 3")) Can't stand to do a +1 for the news item. All the best,
Michael Foord
What's the general consensus on supporting Python 2.5 nowadays?
There is no such consensus :-)
Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays?
At work, we are still using Python 2.5. Six months ago, we started a project to upgrade to 2.7, but we have now more urgent tasks, so the upgrade is delayed to later. Even if we upgrade new clients to 2.7, we will have to continue to support 2.5 for some more months (or years?). In a personal project (the IPy library), I dropped support of Python 2.5 in february 2011. Recently, I got a mail asking me where the previous version of my library (supporting Python 2.4) can be downloaded! Someone is still using Python 2.4: "I'm stuck with python 2.4 in my work environment."
What do people feel?
For a new project, try to support Python 2.5, especially if you would like to write a portable library. For a new application working on Mac OS X, Windows and Linux, you can only support Python 2.6. Victor
On Thu, Dec 22, 2011 at 02:49:06AM +0100, Victor Stinner wrote:
At my work, I'm on RHEL5 and RHEL6. So I'm currently supporting python-2.4 and python-2.6. We're up to 75% RHEL6 (though, not the machines where most of our deployed, custom written apps are running) so I shouldn't have to support python-2.4 for much longer.
As part of work, I package for EPEL5 (addon packages for RHEL5). Sometimes we need a new version of a package or a new package for RHEL5 and thus need to have python-2.4 compatible versions of the package and any of its dependencies. When I no longer need to maintain python-2.4 stuff for work, I'm hoping to not have to do quite so much of this but sometimes I know I'll still get requests to update an existing package to fix a bug or fix a feature and that will require updates of dependent libraries. I'll still be stuck looking for python-2.4 compatible versions of all of these :-(
I agree that libraries have a need to go farther back than applications. I have one library that I support on python-2.3 (for RHEL4... I'm counting down the months on that one :-). Every other library I maintain, I make sure I support at least python-2.4. Application-wise, I currently have to support python-2.4+ but given that Linux distros seem to all have some version out that supports at least python-2.6, I don't think I'll be developing any applications that intentionally support less than that once I get moved away from RHEL-5 at my workplace. -Toshio
participants (20)
-
anatoly techtonik -
Antoine Pitrou -
Barry Warsaw -
Charles Cazabon -
Charles-François Natali -
Chris Withers -
David Malcolm -
Dirkjan Ochtman -
Maciej Fijalkowski -
Mark Hammond -
Matt Joiner -
Michael Foord -
Mike Meyer -
Oleg Broytman -
Sean Reifschneider -
Stefan Behnel -
Tim Wintle -
Toshio Kuratomi -
Victor Stinner -
wang tiezhen