Subject: bug#28160: Support newer version of python

From: Moritz Klammler <[email-masked]>
Date: Fri, 15 Sep 2017 16:57:30 +0200

On 09/15/2017 11:42 AM, Thomas Jahns wrote:
> On 09/15/17 11:17, Mathieu Lirzin wrote:
>> Instead of preemptively adding possible future version of Python that
>> hopefully would be released, I would prefer a solution that removes the
>> need to hard-code them.
>>
>> WDYT?
> 
> Why not parse PATH and filter what pathelem/python* returns for a
> pattern like
> 
> python[0-9.]*
> 
> then test for executability and extract numerically highest (that's
> probably the hardest part) suffix?
> 
> Regards, Thomas

AFAIK, all versions of Python let you do

    $ python -c 'import sys; print(sys.hexversion);'

to print an integer that is increasing strictly monotonic between
releases.  Might be a good way to combine testing whether an executable
file really is a Python interpreter and finding the newest one among
those.  Instead of parsing version numbers, you can then simply compare
plain integers which is easy to do in the shell.

On the other hand, the "hexversion" can be easily computed given a major
and minor version number:

https://docs.python.org/3.7/c-api/apiabiversion.html#apiabiversion