llvm dev - Dec 2012 - [LLVMdev] Minimum Python Version

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 main
reasons:
>
> 1) Python 2.4 and 2.5 are end-of-lifed
> 2) Python 3 is coming
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.

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/lljit
And my try on making a "Pythonic" interface to the IR in Cython:

https://gitorious.org/python-llvm3
> - -Sam
Christoph