# Minimum Python Version **URL:** \ **Category:** LLVM Dev List Archives\ **Created:** [December 1, 2012, 8:57pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510 "2012-12-01T20:57:48Z")\ **Posts on this page:** 20\ **Page:** 1

**Author:** ![indygreg](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/indygreg/32/14403_2.png) [@indygreg](https://discourse.llvm.org/u/indygreg)\ **Post date:** [December 1, 2012, 8:57pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/1 "2012-12-01T20:57:48Z")

I’d like to continue the discussion about minimum Python versions from the “Use multiprocessing instead of threading” thread in its own thread because I feel it warrants additional discussion. In that thread, we were discussing maintaining support for Python 2.4 and 2.5. The latest response is: > My official opinion on Python version support is to maintain old compatibility, unless it is causing large problems with the code. I would like to offer a counter opinion. I believe LLVM should drop support for Python 2.4 and 2.5 for 2 main reasons: 1. Python 2.4 and 2.5 are end-of-lifed 2. Python 3 is coming IMO, #1 should be reason enough. Let me explain #2. All the Python in the tree will need to eventually support Python 3. “Modern” Linux distributions like Ubuntu are already shipping Python 3 as /usr/bin/python (while still offering 2.7 because the overwhelming amount of Python in the wild doesn’t yet work on Python 3). The road to Python 3 for LLVM will likely come via Python code that works under both 2.x and 3.x (I’m assuming nobody wants a flag day). From my personal experience, I can unequivocally say that writing Python that works on both major versions is much easier the closer the Python 2 release is to 3. In other words, It’s much easier to dually support Python 2.7 and 3.x than it is 2.5 and 3.x. I feel the level of pain is pretty bad until you get to Python 2.6. Even then, there are dozens of small bugs in Python 2.6 and even earlier releases of Python 2.7 until 2.7.3 that make dual support difficult (especially in the area of Unicode handling). For these reasons, I urge LLVM to drop support for Python older than 2.6. I would encourage requiring 2.7 (preferably the latest available release - 2.7.3 at this time) at the earliest convenience, but I’m not explicitly asking for it. While continued support for older Pythons is a noble goal and may continue to support people clinging to ancient Python releases, this will only make the path forward more difficult, as it puts an additional burden on those maintaining Python in the tree. FWIW, I’ve been pushing this same argument at Mozilla for the Firefox tree [1], where so far it has been winning. We dropped Python 2.5 about 6 weeks ago and IIRC the only issue was we forgot to update one set of builders before we made the change. We have loosely agreed that we want to move everything to Python 2.7 (then 2.7/3.x and then eventually 3.x) and will be discussing this change in the days ahead. While I’m sure LLVM supports some more esoteric platforms than Firefox, I believe the data point is still relevant and LLVM could make a similar transition without a major headache. [1] [https://groups.google.com/d/topic/mozilla.dev.platform/djN02O03APc/discussion](https://groups.google.com/d/topic/mozilla.dev.platform/djN02O03APc/discussion) Gregory ---

**Author:** ![Eli\_Bendersky1](https://avatars.discourse-cdn.com/v4/letter/e/b487fb/32.png) [@Eli\_Bendersky1](https://discourse.llvm.org/u/Eli_Bendersky1)\ **Post date:** [December 1, 2012, 9:09pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/2 "2012-12-01T21:09:05Z")

+1 I believe the need to support old versions is already causing problems in the code base, the inability to switch to multiprocessing being the most recent example. Again, I realize that some platforms may have older versions of Python pre-installed, but it shouldn't be a problem to install a newer version of Python for the sake of LLVM development on such systems. Eli ---

**Author:** ![DimitryAndric](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/dimitryandric/32/2082_2.png) [@DimitryAndric](https://discourse.llvm.org/u/DimitryAndric)\ **Post date:** [December 1, 2012, 10:08pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/3 "2012-12-01T22:08:18Z")

> I'd like to continue the discussion about minimum Python versions from the "Use multiprocessing instead of threading" thread in its own thread because I feel it warrants additional discussion. ... > For these reasons, I urge LLVM to drop support for Python older than 2.6. I would encourage requiring 2.7 (preferably the latest available release - 2.7.3 at this time) at the earliest convenience, but I'm not explicitly asking for it. While continued support for older Pythons is a noble goal and may continue to support people clinging to ancient Python releases, this will only make the path forward more difficult, as it puts an additional burden on those maintaining Python in the tree. That is all well and good, but please be reminded there are zillions of Red Hat (or CentOS) users out there, stuck with either Python 2.5 or 2.6, who cannot easily upgrade without busting their whole system... ---

**Author:** ![Eli\_Bendersky1](https://avatars.discourse-cdn.com/v4/letter/e/b487fb/32.png) [@Eli\_Bendersky1](https://discourse.llvm.org/u/Eli_Bendersky1)\ **Post date:** [December 1, 2012, 10:14pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/4 "2012-12-01T22:14:32Z")

To install a new Python version one doesn't have to "upgrade" and surely not "bust" their whole system! You can install a newer version of Python alongside older ones, and if everything else fails you can just install it locally and use \*that\* to run the Python scripts LLVM requires. It's quite easy to set up. Eli ---

**Author:** ![indygreg](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/indygreg/32/14403_2.png) [@indygreg](https://discourse.llvm.org/u/indygreg)\ **Post date:** [December 1, 2012, 10:35pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/5 "2012-12-01T22:35:34Z")

I'd like to echo how simple this is. Compiling Python from source is literally configure + make. There are also tools like buildout [1] that make it extremely easy to install multiple Python versions side-by-side. And, since Python is prolific, you can bet that there exists an apt, yum, etc package somewhere. I think simple instructions pointing to these would be sufficient to not upset users of machines "stuck" on Python 2.5 and below. [1] [https://github.com/collective/buildout.python](https://github.com/collective/buildout.python) ---

**Author:** ![jholewinski](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/jholewinski/32/14280_2.png) [@jholewinski](https://discourse.llvm.org/u/jholewinski)\ **Post date:** [December 2, 2012, 12:15am UTC](https://discourse.llvm.org/t/minimum-python-version/25510/6 "2012-12-02T00:15:49Z")

If you’re going to keep your version of LLVM up to date, I don’t see it being a stretch to require a reasonably current version of Python. ---

**Author:** ![Sean\_Silva](https://avatars.discourse-cdn.com/v4/letter/s/ea666f/32.png) [@Sean\_Silva](https://discourse.llvm.org/u/Sean_Silva)\ **Post date:** [December 2, 2012, 4:47am UTC](https://discourse.llvm.org/t/minimum-python-version/25510/7 "2012-12-02T04:47:30Z")

> > My official opinion on Python version support is to maintain old > > compatibility, unless it is causing large problems with the code. > > I would like to offer a counter opinion. I think that we simply need to redefine "old". To me, an "old" version of Python means 2.6. Something that is End-Of-Life'd like 2.{4,5} is not "old", it is "dead". > I believe LLVM should drop support for Python 2.4 and 2.5 for 2 main > reasons: > > 1) Python 2.4 and 2.5 are end-of-lifed > 2) Python 3 is coming +1 -- Sean Silva ---

**Author:** ![Marc\_Driftmeyer](https://avatars.discourse-cdn.com/v4/letter/m/9de0a6/32.png) [@Marc\_Driftmeyer](https://discourse.llvm.org/u/Marc_Driftmeyer)\ **Post date:** [December 3, 2012, 7:18am UTC](https://discourse.llvm.org/t/minimum-python-version/25510/8 "2012-12-03T07:18:42Z")

One of the most conservative distributions is Debian. The python\_defaults package has moved to 2.7.3 in Sid and 2.7.3~rc2-1 in Wheezy (Debian 7.0 now on its 4th beta and soon to be release candidate status). I personally run Sid/Unstable in order to get general release builds of LLVM/Clang \> 2.9, never mind 3.2. It seems reasonable to target 2.7.3 as the oldest python release. - Marc J. Driftmeyer ---

**Author:** ![Tobias\_Grosser6](https://avatars.discourse-cdn.com/v4/letter/t/e95f7d/32.png) [@Tobias\_Grosser6](https://discourse.llvm.org/u/Tobias_Grosser6)\ **Post date:** [December 3, 2012, 11:56am UTC](https://discourse.llvm.org/t/minimum-python-version/25510/9 "2012-12-03T11:56:40Z")

The gcc compile farm currently only has python 2.4 and 2.5. I know Duncan is using it quiet extensively, especially all dragonegg buildbots run on it. I very much agree we should ensure our python scripts are valid python 2.7 and as close as possible to python 3.x. However, as Daniel pointed out, there are still users of older python versions around. We could probably require them to upgrade, but I would like to avoid this, if we can support older python versions without too much trouble. Cheers Tobi ---

**Author:** ![David\_Tweed](https://avatars.discourse-cdn.com/v4/letter/d/9f8e36/32.png) [@David\_Tweed](https://discourse.llvm.org/u/David_Tweed)\ **Post date:** [December 3, 2012, 12:15pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/10 "2012-12-03T12:15:14Z")

Note that RedHat Enterprise Linux has \_very\_ long dates to end-of-extended-life-cycle > **[Red Hat Enterprise Linux](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux)** > > Red Hat Enterprise Linux (RHEL) is a commercial open-source Linux distribution developed by Red Hat for the commercial market. Red Hat Enterprise Linux is released in server versions for x86-64, Power ISA, ARM64, and IBM Z and a desktop version for x86-64. Fedora Linux serves as its upstream source. All of Red Hat's official support and training, together with the Red Hat Certification Program, focuses on the Red Hat Enterprise Linux platform. > The first version of Red Hat Enterprise Linux to bea... RHEL4 has E-EOL of 2015, while RHEL5 has E-EOL of 2020. IIRC last time I checked Centos had a similarly long lifecycle. This is just a piece of evidence about how long some distributions will be "supported". (I looked this up after I accidentally submitted a patch which used post Python-2.4 features that people pointed out broke stuff.) Regards, Dave ---

**Author:** ![Konstantin\_Tokarev](https://avatars.discourse-cdn.com/v4/letter/k/ecd19e/32.png) [@Konstantin\_Tokarev](https://discourse.llvm.org/u/Konstantin_Tokarev)\ **Post date:** [December 3, 2012, 12:31pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/11 "2012-12-03T12:31:45Z")

RHEL/CentOS is more conservative. RHEL 6 ships Python 2.6.6, RHEL 5 (which is still widely used) ships 2.4.3 ---

**Author:** ![jholewinski](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/jholewinski/32/14280_2.png) [@jholewinski](https://discourse.llvm.org/u/jholewinski)\ **Post date:** [December 3, 2012, 1:03pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/12 "2012-12-03T13:03:17Z")

This is an orthogonal issue. There is nothing saying the system Python version has to be 2.7+, just that a local version exists. Python is very simple to build on Linux. Certainly any admin of an RHEL pre-6 cluster can install a version somewhere. Does the default GCC installation on RHEL 4 even build LLVM/Clang anymore, or do you need an “experimental” package of GCC 4.1 or a local build of 4.x? ---

**Author:** ![TNorthover](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/tnorthover/32/1790_2.png) [@TNorthover](https://discourse.llvm.org/u/TNorthover)\ **Post date:** [December 3, 2012, 1:05pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/13 "2012-12-03T13:05:24Z")

> RHEL4 has E-EOL of 2015, while RHEL5 has E-EOL of 2020. IIRC last time I checked Centos had a similarly long lifecycle. In my opinion the burden of such ridiculously long cycles should fall on RedHat and not all other OSS projects. They're presumably getting paid precisely to handle the fact that the world moves on in 10 years. \ Tim. ---

**Author:** ![Stephen\_Checkoway1](https://avatars.discourse-cdn.com/v4/letter/s/8e8cbc/32.png) [@Stephen\_Checkoway1](https://discourse.llvm.org/u/Stephen_Checkoway1)\ **Post date:** [December 3, 2012, 5:59pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/14 "2012-12-03T17:59:17Z")

Debian stable has 2.6.6. If you want to base which version of Python you use based on a particular OS's default (something others don't seem to agree with), then using \_unstable\_ as your baseline seems wrong. ---

**Author:** ![Eli\_Bendersky1](https://avatars.discourse-cdn.com/v4/letter/e/b487fb/32.png) [@Eli\_Bendersky1](https://discourse.llvm.org/u/Eli_Bendersky1)\ **Post date:** [December 3, 2012, 6:04pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/15 "2012-12-03T18:04:06Z")

This is a good point to consider. If RHEL 5 ships 2.4.3 and is officially E-EOL in 2020, and we want to stick to "system Python" everywhere, this means we plan to have our Python code running on Python 2.4.3 until 2020? I doubt that anyone considers this seriously. Eli ---

**Author:** ![R\_P\_Herrold](https://avatars.discourse-cdn.com/v4/letter/r/c4cdca/32.png) [@R\_P\_Herrold](https://discourse.llvm.org/u/R_P_Herrold)\ **Post date:** [December 3, 2012, 6:14pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/16 "2012-12-03T18:14:31Z")

Extended support lifespans, probably not, but main support intervals, certainly tens of thousands of paying customers subscribe to Red Hat's model (or the hundreds of thoudsands usig CentOS rebuild of the same sources) take a stable API quite seriously One thing I am missing here is: What is the \*\* NEED \*\* for chasing a later Python version? -- Russ herrold ---

**Author:** ![Eli\_Bendersky1](https://avatars.discourse-cdn.com/v4/letter/e/b487fb/32.png) [@Eli\_Bendersky1](https://discourse.llvm.org/u/Eli_Bendersky1)\ **Post date:** [December 3, 2012, 6:26pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/17 "2012-12-03T18:26:21Z")

> One thing I am missing here is: > What is the \*\* NEED \*\* for chasing a later > Python version? Did you read Gregory's message that starts this thread? Eli ---

**Author:** ![R\_P\_Herrold](https://avatars.discourse-cdn.com/v4/letter/r/c4cdca/32.png) [@R\_P\_Herrold](https://discourse.llvm.org/u/R_P_Herrold)\ **Post date:** [December 3, 2012, 9:09pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/18 "2012-12-03T21:09:51Z")

I assume you mean the one in the archives: Sat Dec 1 14:57:48 CST 2012 Yes, actually, I did -- it boils down to: it's old, and Python 3 is coming No current problems other than a speculative unicode issue are raised -- Russ herrold ---

**Author:** ![jcranmer](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/jcranmer/32/2576_2.png) [@jcranmer](https://discourse.llvm.org/u/jcranmer)\ **Post date:** [December 3, 2012, 9:53pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/19 "2012-12-03T21:53:40Z")

> Yes, actually, I did -- it boils down to: it's old, and Python 3 is coming Python 3.x is being made the default version of python on some systems, so getting python 2.x/3.x concurrent compatibility will probably be imminently needed. From experience, Python 2.4/Python 3.x concurrent compatibility is just plain impossible. Also, I will point out that arguing that since RHEL 5 still uses 2.4 means we should keep our default at 2.4 is mildly specious, since running Clang on RHEL 5 has required, in my experience, several environment augmentations, most notably because the libc headers there won't compile in C99 mode, and I would be surprised if Clang is properly built by the default version of gcc there. > No current problems other than a speculative unicode issue are raised I don't know any hard examples off the top of my head, but I do definitely remember (while grepping through python docs earlier today) being surprised that some of the functions I use on a consistent basis turned out to have a minimum of python 2.6. ---

**Author:** ![Sean\_Silva](https://avatars.discourse-cdn.com/v4/letter/s/ea666f/32.png) [@Sean\_Silva](https://discourse.llvm.org/u/Sean_Silva)\ **Post date:** [December 3, 2012, 11:28pm UTC](https://discourse.llvm.org/t/minimum-python-version/25510/20 "2012-12-03T23:28:54Z")

Duncan, sorry for roping you into this thread, but it seems that your bots are basically the only concrete need that has been voiced for supporting End-of-life'd (2.4, 2.5) Python versions. Do you have any plans for bringing those bots up to 2.6 or 2.7? If it wouldn't take you a long time, I think it would be beneficial to update so that our Python code can be made Python2+Python3 compatible; Arch Linux and I believe Ubuntu 12.10 ship with Python3 as /usr/bin/python by default, so being able to coexist with both is important. -- Sean Silva [Next page](https://discourse.llvm.org/t/minimum-python-version/25510.md?page=2)