On 4/21/24 16:50, Bruno Haible wrote:
Good point. Yes, Python occasionally (rarely?) makes incompatible changes.
So, I've now created a continuous integration at [2]. If a Python release
is made that breaks gnulib-tool, this CI will notify me shortly afterwards,
and we will have time to adapt gnu
On 2024-04-21 15:38, Bruno Haible wrote:
Hi Paul,
But the concepts of the shell are stuck in the 40-years-ago past.
True, but keeping things simple allows for optimizations like PaSH that
can't reasonably be done to Python.
https://binpa.sh/
Well, I did try PaSh on gnulib-tool — this issue
Hi Paul,
> > But the concepts of the shell are stuck in the 40-years-ago past.
>
> True, but keeping things simple allows for optimizations like PaSH that
> can't reasonably be done to Python.
>
> https://binpa.sh/
Well, I did try PaSh on gnulib-tool — this issue [1] is a testimony.
But what
On 4/21/24 16:50, Bruno Haible wrote:
Bernhard Voelker wrote:
But the concepts of the shell are stuck in the 40-years-ago past.
Hehe, Python also had its 33rd birthday already. :-)
Good point. Yes, Python occasionally (rarely?) makes incompatible changes.
So, I've now created a continuous
On 2024-04-21 07:50, Bruno Haible wrote:
But the concepts of the shell are stuck in the 40-years-ago past.
True, but keeping things simple allows for optimizations like PaSH that
can't reasonably be done to Python.
https://binpa.sh/
Bernhard Voelker wrote:
> The shell seems have to been more safe in that regard.
But the concepts of the shell are stuck in the 40-years-ago past.
That's why it is not recommendable as a programming language for real
programs [1].
> I'd guess most hosts have python installed nowadays ... the ques
