241–250 of 579 posts
Every time I hear news about Python language itself, it sadden me that, in 2025, PyPy is still a separate distinct track from mainline Python. That said, I wonder if GIL-less Python will one day enable GIL-less C FFI? That would be a big win that Python needs.
Earlier quoted context omitted.
You hope it doesn't ? > [Donald Knuth] firmly believes that having an unchanged system that will produce the same output now and in the future is more important than introducing new features This is such a breath of fresh air in a world where everything is considered obsolete after like 3 years. Our industry has a disease, an insatiable hunger for newness over completeness or correctness . There's no reason we can't…
> There's no reason we can't be writing code that lasts 100 years. Code is just math. In theory, yes. In practice, no, because code is not just math, it's math written in a language with an implementation designed to target specific computing hardware, and computing hardware keeps changing. You could have the complete source code of software written 70 years ago, and at best you would need to write new code to emulat…
The real reason for software churn isn't hardware churn, but hardware expansion. It's well known that software expands to use all available hardware resources (or even more, according to Wirth's law).
Earlier quoted context omitted.
> flask Off-topic, but I absolutely loathe new Flask logo. Old one[0] has this vintage, crafty feel. And the new one[1] looks like it was made by a starving high schooler experimenting with WordArt. [0] - https://upload.wikimedia.org/wikipedia/commons/3/3c/Flask_lo... [1] - https://flask.palletsprojects.com/en/stable/_images/flask-na...
I didn't know that they have the new logo before reading your comment. Been 2 years since I last searched flask but yeah the old logo was vintage and I also preferred the old logo and the new logo feels mid/sucks. The old logo is much better.
What are the reasons why nobody uses pypy?
Also: there are some libraries that just don't work on pypy.
Earlier quoted context omitted.
I won’t completely argue against that, and I’ve also adopted Rust for smaller or faster work. Still, I contend that a freaking enormous portion of computing workloads are IO bound to the point that even Python’s speed is Good Enough in an Amdahl’s Law kind of way.
I hear this a lot, but can you really say that you're consistently saturating a 1Gbps line for netcode or 6+ Gbps nvme for disk data? In my experience this doesn't really happen with code that isn't intentionally designed to minimize unnecessary work. A lot of slow parsing tends to get grouped in with io, and this is where python can be most limiting.
Earlier quoted context omitted.
To put in perspective, 300ms is about looping over 30GiB data from RAM, loading 800MiB data from SSD, or doing 1TFLOPS on a single core computer. 300ms to generate a report would be able to go through ~100M rows at least (on a single core). And the implicit assumption that comment I made earlier, of course is not about the 100M rows scan. If there is a confusion, I am sorry.
That's all true, so long as you completely ignore doing any processing on the data, like evaluating the rows and selectively appending some of them into a data structure, then sorting and serializing the results, let alone optimizing the query plan for the state of the system at that moment and deciding whether it makes more sense to hit the indexes or just slurp in the whole table given that N other queries are also…
Earlier quoted context omitted.
The build of Python that I used has tail calls enabled (option --with-tail-call-interp). So that was in place for the results I published. I'm not sure if this optimization applies to recursive tail calls, but if it does, my Fibonacci test should have taken advantage of the optimization.
The tail calls in question are C tail calls inside the inner interpreter loop. They have nothing to do with Python function calls.
Earlier quoted context omitted.
> There's no reason we can't be writing code that lasts 100 years. Code is just math. In theory, yes. In practice, no, because code is not just math, it's math written in a language with an implementation designed to target specific computing hardware, and computing hardware keeps changing. You could have the complete source code of software written 70 years ago, and at best you would need to write new code to emulat…
This is a total red herring, x86 has over 30 years of backwards compatability and the same goes for the basic peripherals. The real reason for software churn isn't hardware churn, but hardware expansion. It's well known that software expands to use all available hardware resources (or even more, according to Wirth's law).
Earlier quoted context omitted.
I mean, Guido had a 2021 Faster CPython presentation where they claimed "5x in 4 years (1.5x per year)"[0]. Developers have significantly walked back those expectations since then. [0] Github slide deck https://github.com/faster-cpython/ideas/blob/main/FasterCPyt...
One important caveat to remember is that this is before a lot of the work on free-threaded python started in full force. A lot of cutting edge work had to be done to support this in the GC but this came with performance penalties. As a result, the trajectory of the Faster CPython effort changed quite a bit. Didn't help Microsoft axed several folks on that team too...
Only after the four-year period was over, during which they only delivered a 1.5x - 2x speedup instead of the projected 5x.