GNU bug report logs -
#28160
Support newer version of python
Previous Next
Full log
View this message in rfc822 format
Hello,
Moritz Klammler <moritz <at> klammler.eu> writes:
> 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
It seems that GNU Pyconfigure has already found a way to build that list
dynamically in m4. Please see PC_PROG_PYTHON macro here:
https://git.savannah.gnu.org/cgit/pyconfigure.git/tree/src/m4/python.m4
I am far from an m4 expert, so if someone is interested in porting that
macro to Automake, please step up.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
This bug report was last modified 7 years and 137 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.