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.
Tobias Grosser <tobias at grosser.es> writes: [snip] So anyone who wishes to tinker on LLVM's Python code would be required to know about the incompatibilities among several versions, and/or about some libraries used to blur those differences. The above would effectively restrict any half-serious tinkering on LLVM's Python code to gurus. So much for an "easy" language.
On Tue, Dec 4, 2012 at 4:27 AM, Tobias Grosser <tobias at grosser.es> wrote:> 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.I'll see what I can do. Since on that machine I only have python3 and python2.7, I can't easily verify that my changes still operate on the desired 2.4 and 2.5. -- Sean Silva
[Devil's Advocate] Since installing a non-system Python is easy, it should be trivial to test against 2.4 and 2.5. :) On Tue, Dec 4, 2012 at 8:59 AM, Sean Silva <silvas at purdue.edu> wrote:> On Tue, Dec 4, 2012 at 4:27 AM, Tobias Grosser <tobias at grosser.es> wrote: > > 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. > > I'll see what I can do. Since on that machine I only have python3 and > python2.7, I can't easily verify that my changes still operate on the > desired 2.4 and 2.5. > > -- Sean Silva > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121204/b2ea1991/attachment.html>
So, I just tried, and basically it's difficult to make progress due to the print statements (since they induce an immediate syntax error). Since 2.4 doesn't support `from __future__ import print_function`, the only alternative I guess is shimming in a print function. This is a maintenance effort that I don't want to do right now (and, TBQH, I feel that the proper maintainer should be responsible for). ddunbar, how does this weight against your "causing large problems with the code" criterion for supporting older versions? As I believe that you are the author and maintainer of lit, are you planning on fixing this compatibility problem? -- Sean Silva On Tue, Dec 4, 2012 at 8:59 AM, Sean Silva <silvas at purdue.edu> wrote:> On Tue, Dec 4, 2012 at 4:27 AM, Tobias Grosser <tobias at grosser.es> wrote: >> 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. > > I'll see what I can do. Since on that machine I only have python3 and > python2.7, I can't easily verify that my changes still operate on the > desired 2.4 and 2.5. > > -- Sean Silva
On 12/4/12 1:27 AM, Tobias Grosser wrote:>> 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 syntax > Yes, 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. >There is also the difference for handling exceptions. Python 2.4 and 2.5 only support "except Exception, e" syntax. Python 2.6 and 2.7 support that and "except Exception as e." Python 3.0 and above only support "except Exception as e." So, exception handling code that needs to work on 2.4/2.5 through 3 needs to be something like: except Exception: e = sys.exc_info[1] It's ugly. As I said in the initial message in this thread, supporting Python 3 is easier the closer the Python 2 release is to 3.0. There's the big ticket language additions, which are nice. But what really sways me are all the little bugs in the point releases, especially around Unicode handling. e.g. this will fail in all 2.x releases except 2.7.3 (the newest): from __future__ import unicode_literals ... env = dict(os.environ) env['FOO'] = 'bar' output = subprocess.check_output([command], env=env) It fails because something in the stdlib is expecting str, not unicode. When you start supporting 2/3, you find these types of bugs all the time when working with older Python releases. The remedy is to target the newest and least buggy 2.x release possible.