[LLVMdev] Minimum Python Version

[Tobias Grosser]

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