Fortunately it should be slowing down now. The big transition was getting everyone on board with PEP 517, especially converting legacy Setuptools projects.

I've been hearing something like this about Python builds every two or three years for decades. How long until the next "big transition" is "converting legacy PEP 517 projects"?

Hopefully never.

Hopefully, sure. But why should we believe that this time is different?

The main difference now is there is an actual standard rather than a de facto tool that becomes the standard.

The idea is that different tools may rise and fall in popularity but they should all be following the standard so the compatability breaks should be minimal.

Will it work? No idea, but it's the best attempt to make things work well for everyone yet.

Python 3.12 might be the biggest churn moment, but there are probably a few more down the road, such as dropping legacy version specifiers.

For pure CPU computation Windows is just as fast as Linux since 99.9% of the time it's your code running and not the OS.

Depending on the code you're running, calling convention can matter a lot. The SysV ABI will use xmm/ymm/zmm automatically, whereas on Windows you have to opt into it with __vectorcall.

Not true. Changes to the OS, particularly to the scheduler, can affect CPU-bound work a great deal. It's "your code", but the OS decides when and where it runs. For example, the changes between Linux 6.5 and Linux 6.6 led to a >20% uplift in TensorFlow and some smaller uplifts to Blender. This is the same software on the same hardware.

https://www.phoronix.com/review/linux66-epyc-xeon/3

I couldn't track down a more detailed scheduler-specific benchmark. I remember reading one on Phoronix a few months back...

Not many compute clusters run windows