[bug#68416] [PATCH] python: add 3.20 - 3.16 to the version search list
On Mon, Jan 15, 2024, at 7:02 PM, Jacob Bachmeyer wrote:
> Frederic Berat wrote:
>> pythons="python python2 python3"
>> for i in {20..0};do pythons="$pythons python3.$i";done
>> for i in {7..0};do pythons="$pythons python2.$i";done
>>
>> m4_define_default([_AM_PYTHON_INTERPRETER_LIST], [$pythons])
>
> The {20..0} is a syntax unfamiliar to me, yet even Bash 3 has it...
> interesting.
Just responding to this specific thing: the POSIX shell spec doesn't
include any form of brace expansion. ksh93 (-2008) does recognize
both {a,b,c} and {1..10}, but NetBSD /bin/sh and /bin/ksh don't.
The `seq` utility is not portable either.
zw
[bug#68416] [PATCH] python: add 3.20 - 3.16 to the version search list
Sorry to be a curmudgeon, but I don't see an advantage to merely
dynamically synthesizing the static list of versions. If anything, I
think statically listing everything in text is clearer and less
error-prone.
What would be an improvement is to not to have this list of versions at
all. I guess we could consider each element of PATH in turn, looking for
executables named python\d\.?\d+ (something like that), but it seems
fragile not to use AC_PATH_PROGS. Dealing with .exe, sorting the
resulting possible set of names correctly ("by reverse version"), and
other niggling details.
So I guess in the end my inclination is to leave bad enough alone. Might
as well close this.
Thanks to everyone for the input.
Karl
P.S. As for Python 4: no, I was not being facetious about Python's
demonstrated lack of interest in compatibility. It doesn't seem like it
would hurt anything much to add python4 and python4.0, but I'm content
to never mind that, and await developments.
[bug#68416] [PATCH] python: add 3.20 - 3.16 to the version search list
Frederic Berat wrote:
On Sun, Jan 14, 2024 at 3:13 AM Karl Berry wrote:
With Python 3.12 out now, and 3.13 out in ~9 months, the existing
runway
is running out. Bump up to 3.20 for the next Automake release.
Applied, thanks.
Not proposing to try anything for our upcoming release, but I wonder if
there is some more general way to handle Python versions? We don't have
to laboriously list every possible version for anything else.
That may not be the most clever way to do it, but you can probably build
the list dynamically at least, with something like (untested):
pythons="python python2 python3"
for i in {20..0};do pythons="$pythons python3.$i";done
for i in {7..0};do pythons="$pythons python2.$i";done
m4_define_default([_AM_PYTHON_INTERPRETER_LIST], [$pythons])
The {20..0} is a syntax unfamiliar to me, yet even Bash 3 has it...
interesting. Also interesting that it is brace expansion, so you could do:
pythons=`echo python{,2,3} python3.{20..0} python2.{7..0}`
The use of command substitution and echo works around the small catch
that brace expansion does not occur inside double quotes. However,
brace expansion does occur inside a command substitution inside double
quotes, but the result of command substitution as a variable assignment
is not subject to word splitting, so the double quotes can be omitted.
I wonder if all shells that allow {20..0} also allow $() for command
substitution, or if this code must be valid in shells that predate POSIX...
Oh wait, after reviewing the thread, I find that this is in m4 macros.
Yes, it could be dynamically produced, but not using shell iteration
constructs or expansions. Macros in m4 are allowed to use tail
recursion, and counted iteration is possible to implement (and autoconf
provides some macros for it).
The required quoting is "fun" and Automake may complain that this
appears to be underquoted: (untested; the fine details of the quoting
may be wrong)
m4_define_default([_AM_PYTHON_INTERPRETER_LIST], dnl
[python python2 python3] dnl
m4_for(i, 20, 0, -1, [ python3.i]) dnl
m4_for(i, 7, 0, -1, [ python2.i]))
As written, this might lead to some extra spaces in the interpreter
list, but the shell will ignore those when running configure.
-- Jacob
[bug#68416] [PATCH] python: add 3.20 - 3.16 to the version search list
On Sun, Jan 14, 2024 at 3:13 AM Karl Berry wrote:
> With Python 3.12 out now, and 3.13 out in ~9 months, the existing
> runway
> is running out. Bump up to 3.20 for the next Automake release.
>
> Applied, thanks.
>
> Not proposing to try anything for our upcoming release, but I wonder if
> there is some more general way to handle Python versions? We don't have
> to laboriously list every possible version for anything else.
>
That may not be the most clever way to do it, but you can probably build
the list dynamically at least, with something like (untested):
pythons="python python2 python3"
for i in {20..0};do pythons="$pythons python3.$i";done
for i in {7..0};do pythons="$pythons python2.$i";done
m4_define_default([_AM_PYTHON_INTERPRETER_LIST], [$pythons])
> As things are, I'm tempted to include 4.20-4.1 too, because their next
> major incompatibility will probably come sooner rather than later ...
>
> wdyt? --thanks, karl.
>
>
>
>
[bug#68416] [PATCH] python: add 3.20 - 3.16 to the version search list
On 13 Jan 2024 19:12, Karl Berry wrote: > Not proposing to try anything for our upcoming release, but I wonder if > there is some more general way to handle Python versions? We don't have > to laboriously list every possible version for anything else. yeah, it sucks. i'm on the fence whether we should have python support in automake at all tbh. > As things are, I'm tempted to include 4.20-4.1 too, because their next > major incompatibility will probably come sooner rather than later ... i assume you're being facetious here -- i think the Python folks learned their lesson with 2->3 and won't do another major bump. -mike signature.asc Description: PGP signature
[bug#68416] [PATCH] python: add 3.20 - 3.16 to the version search list
With Python 3.12 out now, and 3.13 out in ~9 months, the existing runway is running out. Bump up to 3.20 for the next Automake release. Applied, thanks. Not proposing to try anything for our upcoming release, but I wonder if there is some more general way to handle Python versions? We don't have to laboriously list every possible version for anything else. As things are, I'm tempted to include 4.20-4.1 too, because their next major incompatibility will probably come sooner rather than later ... wdyt? --thanks, karl.
[bug#68416] [PATCH] python: add 3.20 - 3.16 to the version search list
With Python 3.12 out now, and 3.13 out in ~9 months, the existing runway is running out. Bump up to 3.20 for the next Automake release. * m4/python.m4: Add python3.20 - python3.16. * NEWS: Mention new Python versions. --- NEWS | 2 +- m4/python.m4 | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index c4e3d58ecb27..c53573a0abbb 100644 --- a/NEWS +++ b/NEWS @@ -12,7 +12,7 @@ New in 1.17: version. If a specific version of Python 2 is still needed, the $PYTHON variable should be set beforehand. - - AM_PATH_PYTHON will also search for Python versions 3.15 through 3.10. + - AM_PATH_PYTHON will also search for Python versions 3.20 through 3.10. It previously searched for 3.9 through 3.0. (bug#53530) - RANLIB may be overridden on a per-target basis. diff --git a/m4/python.m4 b/m4/python.m4 index 8d4e4d21585b..2de57c52ae81 100644 --- a/m4/python.m4 +++ b/m4/python.m4 @@ -38,6 +38,7 @@ AC_DEFUN([AM_PATH_PYTHON], dnl supported. (2.0 was released on October 16, 2000). m4_define_default([_AM_PYTHON_INTERPRETER_LIST], [python python3 dnl + python3.20 python3.19 python3.18 python3.17 python3.16 dnl python3.15 python3.14 python3.13 python3.12 python3.11 python3.10 dnl python3.9 python3.8 python3.7 python3.6 python3.5 python3.4 python3.3 dnl python3.2 python3.1 python3.0 dnl -- 2.43.0
