[LLVMdev] Minimum Python Version

[Tobias Grosser]

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 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.

> 
> 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.