Re: future Python evolution
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 gnulib-tool, even before the new Python release lands in the various distros. great, thanks! (sorry, the mail didn't go out earlier.) Have a nice day, Berny
Re: future Python evolution
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 [1] is a testimony. I agree that PaSh is not ready to tackle 'configure' scripts yet. However, it's promising and I wouldn't expect similar promise from Python script acceleration. A better way to exploit PaSh would be to modify Autoconf to use it effectively. This of course would be nontrivial, though it shouldn't be *that* hard. But what can you expect from a parallelization approach? On, say, a quad-core processor you can expect at most a 4x speedup. Quad-core is not the wave of the future. Even the three-year-old (and now discontinued) Xeon W-1350 I'm typing this on (which was trailing edge and bottom of the line when it came out - hey, I'm a cheapskate!) is 6 cores and 12 threads. And if you've been following recent CPU news you're aware of the big core counts coming down the pipeline. We should be engineering for these future systems, and not worry too much about yesterday's quad-core CPUs. And if one can't get a decent single node to develop on, there's always DiSh on the horizon https://github.com/binpash/dish
Re: future Python evolution
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 can you expect from a parallelization approach? On, say, a quad-core processor you can expect at most a 4x speedup. Which means, the parallelized gnulib-tool.sh would still be 2 times to 25 times slower than the Python rewrite. Also, has PaSh been applied to configure scripts? I recall that configure script parallelization had been a topic for Ralf Wildenhues (before Google swallowed him). Bruno [1] https://github.com/binpash/pash/issues/573
Re: future Python evolution
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 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 gnulib-tool, even before the new Python release lands in the various distros. great, thanks! Have a nice day, Berny
Re: future Python evolution
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/
Re: future Python evolution
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 question is > rather which version of it, and how compatible it is: > now it's <3.7 which is incompatible (according to your mail), > but in future there might come more incompatibilities with newer versions. 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 gnulib-tool, even before the new Python release lands in the various distros. Bruno [1] https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00160.html [2] https://gitlab.com/gnulib/gnulib-tool-ci
