4 ms·
I see your point, but it directly conflicts with the effort many people put into producing extremely fast libraries for specific purposes, such as web framework
by uniqueuid 4y ago
I see your point, but it directly conflicts with the effort many people put into producing extremely fast libraries for specific purposes, such as web frameworks (benchmarked extensively), ORMs and things like json and date parsing, as seen in the excellent ciso8601 [1] for example.
[1] https://github.com/closeio/ciso8601 https://github.com/closeio/ciso8601
- dagmx 4y agoI disagree that it conflicts. There's an (implied) ceiling on Python performance, even after optimizations. The fear has always been that removing the design choices that cause that ceiling, would result in a different, incompatible language or runtime. If everyone knows it's never going to reach the performance needed for high performance work, and there's already an excellent escape hatch in the form of C extensions, then why would people be spending time on the middle ground of performance? It'll still be too slow to do the things required, so people will still be going out to C for them. Personally though, I'm glad for any performance increases. Python runs in so much critical infrastructure, that even a few percent would likely be a considerable energy savings when spread out over all users. Of course that assumes people upgrade their versions...but the community tends to be slow to do so in my experience.
- mywittyname 4y agoIsn't this the point made in the last paragraph, about how people find ways around the limitations?