On 12/04/2012 12:28 AM, Sean Silva wrote:> On Mon, Dec 3, 2012 at 6:56 AM, Tobias Grosser<tobias at grosser.es> wrote: >> 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. > > 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.Hi Sean, several people already asked what are the concrete benefits of breaking support for end-of-life python versions? It is not our job to force people to upgrade. In the absence of actual benefits on our side, not supporting older versions causes unnecessary overhead. In this case we know there is overhead for Duncan, but I am sure I will at some point log into an old system and would have to install a newer python to use LLVM. If there is no direct benefit for us, I would definitely like to avoid this additional overhead. My experience with cindex.py has been, that maintaining backward compatibility was never a big issue. The threading/process stuff seems the first issue that can not be worked around trivially. However, the necessary workaround for windows makes it apparently easy to support older python versions. Hence, I don't see a reason to stop support for older python versions until we find a case where supporting them is not trivial any more. This use case will then also help us to take an educated decision on what should the minimal supported python version be. Support for python 3 seems a good thing. What constructs in our code block the move to python 3? Cheers Tobi
> several people already asked what are the concrete benefits of breaking support for end-of-life python versions?Generally I think the only compelling argument is "for a given level of maintenance effort, you either sacrifice support for old-dead versions, or new versions", and obviously new versions should be preferred. The question is how much does it cost to interoperate. On Mon, Dec 3, 2012 at 7:01 PM, Tobias Grosser <tobias at grosser.es> wrote:> Support for python 3 seems a good thing. What constructs in our code block > the move to python 3?I haven't looked in-depth at this, but just trying to import a couple lit modules I get a lot of syntax errors like:>>> import ShUtil.pyTraceback (most recent call last): File "<stdin>", line 1, in <module> File "ShUtil.py", line 119 raise ValueError,"Fast path failure: %r != %r" % (res, reference) ^ SyntaxError: invalid syntax On this machine I have had to install python2 and symlink it in a high-priority part of my PATH just to be able to run the test suite, for example. Is this really any different than forcing people running older versions to upgrade? The primary difference is that while the number of people running older versions is declining, the number of people running python3 will only increase. I believe that 2.6 was the first version that had the __future__ import print_function available, which means that python 2.4 and 2.5 would not be able to use print statements if they are to interoperate with py3k. There is also __cmp__() which has been removed in python3 and I saw in a couple places. The bottom line is that basically every guide to porting/interoperating with python3 starts with "step 1: use python 2.6 at least, ideally 2.7". Given the need to interoperate with py3k, the need to get to 2.6 at least is compelling. http://python3porting.com/preparing.html ("The first step in the porting process is to get your code running in Python 2.6 or 2.7.") https://wiki.ubuntu.com/Python/3 ("Target Python 3.2, 2.7, and optionally 2.6. Ignore anything older than that.") http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python/ ("2.6 is your Baseline") It would be nice if whoever maintains lit (ddunbar?) would sit down one day and try running it with python3 and just hammering out the problems. -- Sean Silva
On Tue, Dec 4, 2012, at 03:23 AM, Sean Silva wrote:> > several people already asked what are the concrete benefits of breaking support for end-of-life python versions? > > Generally I think the only compelling argument is "for a given level > of maintenance effort, you either sacrifice support for old-dead > versions, or new versions", and obviously new versions should be > preferred. The question is how much does it cost to interoperate.Sure. The only thing I ask for is to first figure out what is needed to move to 3.0 and to see if the requiered changes work only for python 2.6/2.7 or if they also happen to work with python 2.5 or even 2.4.> On Mon, Dec 3, 2012 at 7:01 PM, Tobias Grosser <tobias at grosser.es> wrote: > > Support for python 3 seems a good thing. What constructs in our code block > > the move to python 3? > > I haven't looked in-depth at this, but just trying to import a couple > lit modules I get a lot of syntax errors like: > > >>> import ShUtil.py > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "ShUtil.py", line 119 > raise ValueError,"Fast path failure: %r != %r" % (res, reference) > ^ > SyntaxError: invalid syntaxYes, this is 2.x python syntax. To support 3.x you need to change it to: msg = "Fast path failure: %r != %r" % (res, reference) raise ValueError(msg) This code should now work for 3.x and 2.6. However, it also works without any problem on python 2.4. It is therefore a good example to show that python 3.x support does not always require removing support for older python version.> > On this machine I have had to install python2 and symlink it in a > high-priority part of my PATH just to be able to run the test suite, > for example. Is this really any different than forcing people running > older versions to upgrade? The primary difference is that while the > number of people running older versions is declining, the number of > people running python3 will only increase.I am not against python3 support. I am against unnecessarily forcing people to move to a different python 2.x version.> I believe that 2.6 was the first version that had the __future__ > import print_function available, which means that python 2.4 and 2.5 > would not be able to use print statements if they are to interoperate > with py3k.This is a very valid point. There are other options like e.g. the six python 2&3 compatibility library http://pypi.python.org/pypi/six, which supports python 2.4. It also provides a generic print statement. Using such a compatibility library could make sense in general. If it does, python 2.4 support may actual not too involved.> There is also __cmp__() which has been removed in python3 and I saw in > a couple places.That is fine. However, I bet that the replacement code that fixes this is valid python 2.4.> The bottom line is that basically every guide to > porting/interoperating with python3 starts with "step 1: use python > 2.6 at least, ideally 2.7". Given the need to interoperate with py3k, > the need to get to 2.6 at least is compelling.Our code is fully 2.7 compatible. They ask for that compatibility, not to introduce features that only work in 2.7 but not in 2.4.> http://python3porting.com/preparing.html ("The first step in the > porting process is to get your code running in Python 2.6 or 2.7.") > https://wiki.ubuntu.com/Python/3 ("Target Python 3.2, 2.7, and > optionally 2.6. Ignore anything older than that.") > http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python/ ("2.6 is > your Baseline") > > It would be nice if whoever maintains lit (ddunbar?) would sit down > one day and try running it with python3 and just hammering out the > problems.Why don't you give it a try. This will also help us to understand where the biggest problems are and if the necessary changes make supporting python 2.4 hard.