Exciting changes for python [LWN.net]

Exciting changes for python

Posted Jul 15, 2025 23:39 UTC (Tue) by marcH (subscriber, #57642)
In reply to: Exciting changes for python by Bluehorn
Parent article: Following up on the Python JIT

> We don't compute much, we just keep data organized for the user. So there is no single bottleneck, we can only optimize peaks of 7% at most from the flame graph.

If you don't "compute" much, then why is the programming language the bottleneck?

All languages are equal when waiting for storage, network, databases, user input, etc. In that case, optimizing requires re-architecturing data and caching and that's generally not language specific. Except higher level languages make it much easier, safer and faster to experiment with different designs and strategies.

to post comments

Exciting changes for python

Posted Jul 16, 2025 8:10 UTC (Wed) by taladar (subscriber, #68407) [Link] (2 responses)

I wouldn't say Python makes it safe or easy to change designs and strategies. That is precisely where you want a compiler that tells you all the spots where you accidentally broke something while refactoring.

Exciting changes for python

Posted Jul 16, 2025 15:14 UTC (Wed) by marcH (subscriber, #57642) [Link] (1 responses)

I wrote "experiment". Obviously, interpreted languages catch much fewer bugs at compile time and require a lot more test coverage. You absolutely need a ton of test coverage when refactoring and it tends to be never enough. Introducing regressions in less usual cases is bad indeed, but that does not get in the way when experimenting new designs to address performance bottlenecks in _common_ use cases. It only comes back and bites you later but that's not specific to performance, that's just the nature of all interpreted languages and that's the price to pay for a much faster development and prototyping loop.

When I wrote "safer" I had memory corruption and C/C++ specifically in mind - these are always the most-time consuming bugs by several orders of magnitude. There are indeed many other options besides Python and C/C++ and some may be better than either depending on the use case.

Compared to lower level languages, Python saves time prototyping not just because you write less code but also because there are very high level libraries and approaches to choose from, especially for I/O and concurrency.

Exciting changes for python

Posted Jul 16, 2025 18:24 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> especially for I/O and concurrency.

Except for inotify for some reason. Granted, this was in 2015 when the Great Python 3 Disruption was still in full swing, but the only inotify libraries I could find were either wrapped up in way-too-large frameworks (e.g., Twisted) or abandoned by their maintainers on Python2 (possibly until asyncio was established?).