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: On Fri, Nov 30, 2012 at 1:40 PM, Daniel Dunbar <daniel at zuster.org> wrote:> 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 Gregory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121201/6318c557/attachment.html>
On Sat, Dec 1, 2012 at 12:57 PM, Gregory Szorc <gregory.szorc at gmail.com> wrote:> 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: > > On Fri, Nov 30, 2012 at 1:40 PM, Daniel Dunbar <daniel at zuster.org> wrote: >> >> 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 >+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
On 2012-12-01 21:57, Gregory Szorc wrote:> 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...
On Sat, Dec 1, 2012 at 2:08 PM, Dimitry Andric <dimitry at andric.com> wrote:> On 2012-12-01 21:57, Gregory Szorc wrote: >> >> 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... > ___________________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
> On Fri, Nov 30, 2012 at 1:40 PM, Daniel Dunbar <daniel at zuster.org> wrote: >> >> 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 On Sat, Dec 1, 2012 at 3:57 PM, Gregory Szorc <gregory.szorc at gmail.com> wrote:> 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: > > On Fri, Nov 30, 2012 at 1:40 PM, Daniel Dunbar <daniel at zuster.org> wrote: >> >> 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 > > Gregory > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
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 On 12/01/2012 12:57 PM, Gregory Szorc wrote:> 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: > > On Fri, Nov 30, 2012 at 1:40 PM, Daniel Dunbar <daniel at zuster.org > <mailto:daniel at zuster.org>> wrote: > > 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 > > Gregory > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- Marc J. Driftmeyer Email :: mjd at reanimality.com <mailto:mjd at reanimality.com> Web :: http://www.reanimality.com Cell :: (509) 435-5212 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121202/8eecd833/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: mjd.vcf Type: text/x-vcard Size: 317 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121202/8eecd833/attachment.vcf>
On 12/03/2012 08:18 AM, Marc J. Driftmeyer wrote:> 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.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
Note that RedHat Enterprise Linux has _very_ long dates to end-of-extended-life-cycle http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux 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 -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dimitry Andric Sent: 01 December 2012 22:08 To: Gregory Szorc Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Minimum Python Version On 2012-12-01 21:57, Gregory Szorc wrote:> 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... _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
03.12.2012, 11:44, "Marc J. Driftmeyer" <mjd at reanimality.com>:> One of the most conservative distributions is Debian.RHEL/CentOS is more conservative. RHEL 6 ships Python 2.6.6, RHEL 5 (which is still widely used) ships 2.4.3 -- Regards, Konstantin
On Dec 3, 2012, at 2:18 AM, Marc J. Driftmeyer <mjd at reanimality.com> wrote:> 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.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. -- Stephen Checkoway
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/1/12 12:57 PM, Gregory Szorc wrote:> > I believe LLVM should drop support for Python 2.4 and 2.5 for 2 mainreasons:> > 1) Python 2.4 and 2.5 are end-of-lifed > 2) Python 3 is comingEntering the discussion a bit late, but I'd like to make a plug here for using Cython for any official Python bindings. There are numerous advantages to using it over writing extension modules by hand in C, but one advantage that is relevant to this discussion: Cython supports Python 2 and 3 from the same source code, so it goes a long way to easing maintenance. http://docs.cython.org/src/userguide/pyrex_differences.html As an example of how to write such an interface, a minimalist JIT interface: https://github.com/samrushing/lljit - -Sam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAlDBOtcACgkQHBId2kpNDRZ5qgCfd6xlk5poF7fGEAWerGTxUknv z8sAn1PaPmTcc8vgycc8H6DOsfz3Jrk6 =4BMZ -----END PGP SIGNATURE-----
Am Donnerstag, 6. Dezember 2012, 16:39:51 schrieb Sam Rushing:> [...] > Entering the discussion a bit late, but I'd like to make a plug here for > using Cython for any official Python bindings. There are numerous > advantages to using it over writing extension modules by hand in C, but > one advantage that is relevant to this discussion: Cython supports > Python 2 and 3 from the same source code, so it goes a long way to > easing maintenance.As far as I understood the thread was mostly about the utilities written in Python, not the bindings. However, I'd second that.> http://docs.cython.org/src/userguide/pyrex_differences.html > > As an example of how to write such an interface, a minimalist JIT interface: > > https://github.com/samrushing/lljitAnd my try on making a "Pythonic" interface to the IR in Cython: https://gitorious.org/python-llvm3> - -SamChristoph
Maybe Matching Threads
- [LLVMdev] Minimum Python Version
- [LLVMdev] Changes to Debian's linker object files breaks building LLVM [crti.o, crt1.o, crtn.o]
- [LLVMdev] Changes to Debian's linker object files breaks building LLVM [crti.o, crt1.o, crtn.o]
- [LLVMdev] Update CMakeLists.txt for Target Hexagon to adjust MCTargetDesc path for HexagonMCAsmInfo.cpp
- [LLVMdev] Changes to Debian's linker object files breaks building LLVM [crti.o, crt1.o, crtn.o]