How Python was Shaped by leaky Internals, Armin Ronacher, Flask framework on HackerTube: recommended by 15 Hacker News commenters across 16 separate months, 2017–2025.
talk · advanced · evergreen
Armin Ronacher, creator of Flask, explains how CPython's internals and C API leak into the language's semantics. Using examples like the complexity of the add operation, he shows why Python is hard to optimize or reimplement.
It is HN's standard answer to why Python cannot easily get much faster, and is recommended by people who work on JITs and alternative runtimes.
“This excellent talk describes how the semantics of the "add" operation are much more complex than generally described.”
20 Hacker News comments link this video. Each one links back to its thread.
I thought this presentation by Armin Ronacher (the creator of Flask and Jinja) was very enlightening: How Python was Shaped by leaky Internals(2016): ▶ this video See also this HN post (Attempts to make Python fast): [link]
in “Faster CPython (2021) [pdf]” · View on HN
I think "a + b" is a good example. I really recommend the talk I linked ( ▶ this video ), it gets deep into this stuff. I don't think anyone benefits from "a + b" having so many special cases.
in “Pyjion – A Python JIT Compiler” · View on HN
Python is difficult to optimize due to complex language semantics. This excellent talk describes how the semantics of the "add" operation are much more complex than generally described. a+b is not just a.__add__(b), you have to read 200+ lines of CPython interpreter code to fully resolve its semantics: ▶ this video Not saying it's impossible, but it's more of an uphill battle than optimizing other languages that have more regular semantics. Python is also constrained by its C API, which is a very low-level and exposes a lot of implementation details to C extensions. Changing the API could improve performance but it would also make Python incompatible with a large ecosystem of C extensions. I sometimes wish for Python to define a new C API that exposes far less, and to begin a long-term migration towards the new API so that eventually the interpreter would be less constrained. It would be a large migration, but unlike Python 2 -> 3 it wouldn't affect everyday users, only extension authors. I don't know if it will ever happen, but a person can dream.
in “Writing Python Extensions in Assembly” · View on HN
As the OP states: > mutable interpreter frames, global interpreter locks, shared global state, type slots On top of this, Python is extremely dynamic and nothing can be assured without running through the code. So this leads to needing JITs to improve performance which then give a slow start up time and increased complexity. Even with JIT, Python is just not fast thanks to the above issues and it's overall dynamism. It can be optimised and for sure there's some impressive attempts at doing so. However I don't think pure Python will ever be considered "fast" as these things necessarily get in the way. I highly recommend the two videos posted here that go into more detail as to why there are limits to how far optimisation can go: ▶ this video [link]
in “Attempts to make Python fast” · View on HN
I highly recommend this talk by Armin Ronacher as an accompaniment (or prologue, or epilogue) to the article: "How Python was shaped by leaky internals", ▶ this video
in “Python's Innards: Introduction (2010)” · View on HN
As others have mentioned, Python does have JIT compilers. The problem is that havign a JIT doesn't solve the problem. PyPy is often a factor of 10 behind julia performance and projects like Numba, PyTorch (the PyTorch people had to build their own Python JIT compiler yikes!), etc. will always have a more restricted scope than a project like Julia because Python's very semantics make many optimizations impossible. Here's a great talk from the author of the famous Flask library in Python: ▶ this video where he discusses the fundamental problems with Python's semantics. If you fix these problems, you will end up changing Python so fundamentaly that you'll really have a new language. Generic CPython 3._ code will certainly not be compatible with it.
in “JuliaLang: The Ingredients for a Composable Programming Language” · View on HN
Python needs a new runtime. This talk shows how bad of shape it's really in. ▶ this video Basically, the language doesn't have a "spec" per-se. The language is whatever the defacto CPython implementation happens to do within it's giant eval loop. Another great talk about CPython internals: [link]
in “Grumpy: Go running Python” · View on HN
VWWHFSfQ, you may already know this, but: I recommend this talk by Armin Ronacher (Flask creator) on how Python's implementation internals contribute to the difficulties of making Python faster. ▶ this video One case study Ronacher gets into is the torturous path taken through the Python interpreter (runtime?) when you evaluate `__add__`. Fascinating stuff.
in “A tail calling interpreter for Python (already landed in CPython)” · View on HN
You can't have Python run that much faster without loosing lots of features. I guess if they open sourced it, people wouldn't be that impressed with what they implemented. This video [0] from the creator of Flask explains it quite well. Here [1] is Guido talking about Mojo being in early days and sharing some technical details. [0] ▶ this video [1] [link]
in “Mojo: It’s Finally Here” · View on HN
I know very little about Python, but I would suggest these talks about a few ways in which Python is unique. They won't teach you Python, but they might help in making sense of the confusing bits you might encounter: How Python was Shaped by leaky Internals, Armin Ronacher: ▶ this video What Does It Take To Be An Expert At Python?: [link] and maybe also When Python Practices Go Wrong: [link]
in “Ask HN: Best way to learn advanced Python?” · View on HN
Python's classes can change dynamically though during runtime. So each iteration of a loop would need to check if the shape has changed. I'm no Python expert though, so please correct me if I'm mistaken. But it's more than that. There's a really nice talk here from the creator of the Flask framework about a bunch of different semantic choices in the language design, leak out into the ecosystem and make many optimizations impossible: ▶ this video
in “Is Julia Really Fast?” · View on HN
Armin Ronacher, author Flask, actually has a good talk about this. The gist of it the way Python's internals leak into the language makes it very difficult to build a performant JIT that wouldn't break a large amount of userspace code. Python lets you do _far_ more shenanigans that Javascript does; and a lot of large libraries depend on some of that behavior. Breaking it would probably cause a new 2 -> 3 situation. ▶ this video
in “Node.js 14 is over 20x faster than Python3.8 for fib(n)” · View on HN
I found the following talks by Armin Romacher very informative on these topics (C API, why python is more difficult to speed up than JS). ▶ this video [link] I wish these were the things Python 3 addressed, rather than Unicode. I guess it's much more obvious in hindsight than back when Python 3 was designed.
in “Attempts to make Python fast” · View on HN
Python's success is richly deserved. The fact that it has been a long time coming (Python is almost 30 years old!) is an indication of the amount of sheer effort involved, and should give heart for all those working on building up the next generation of languages. Since this forum is likely to have some folks looking towards the future, I found interesting a couple of talks by Python veteran Armin Ronacher [1, 2]. Watching that presentation makes me wonder whether I should think of this in the context of "Worse is better". That said, Python's runtime introspection is such a killer feature that it's difficult to explain how empowering it feels for someone who is relatively new to programming. [1]: How Python was Shaped by leaky Internals -- ▶ this video [2]: A Python for Future Generations -- [link]
in “Python Is Eating the World” · View on HN
There's a reason most high-performance Python libraries are not written that way, and core routines are just written in C instead. Proof of the pudding is in the eating! See this talk by Armin Ronacher (creator of Flask) on why the design of python makes it fundamentally unfriendly to performance optimizations: ▶ this video Julia has be designed ground up to avoid several such problems. See this discussion: [link] If your domain falls under the umbrella of numerical and scientific computing, writing Julia is as painless as writing python, with code that automatically runs roughly as fast as C. If you're used to writing numpy, you can hit the ground running in Julia, with maybe a few hours to become comfortable with the slightly different syntax and the names of useful libraries.
in “How Numba and Cython speed up Python code” · View on HN
Perhaps the best way to understand what makes Julia fast is to watch these two videos about Python and R and what makes them so hard to optimize: ▶ this video [link] Take everything mentioned in these videos that make Python and R really hard to optimize and don't do those things :D
in “My favorite things that are coming with Julia 1.0” · View on HN
Instead of typing a long list, I'll just refer you to this talk: ▶ this video Some of that has been fixed / got make up applied to play pretend.
in “RTL MJIT – Register transfer language VM and JIT for Ruby” · View on HN
Someone else already posted this link: ▶ this video It explains why CPython can't improve on many things.
in “Grumpy: Go running Python” · View on HN
You're arguing with mitsuhiko, he's given entire talks on this subject. ▶ this video PyPy is faster for pure Python code, but that comes at the expense of having a far slower interface with C code. There's an entire ecosystem built around the fact that while Python itself is slow, it can very easily interface with native code (Numpy, Scipy, OpenCV) with very little overhead. So sure, you can make Python much faster, if you're willing to piss off the very Python users who care the most about performance in the first place (the data science / ML people and anyone else using native extensions).
in “Attempts to make Python fast” · View on HN
Some of these are pretty simple and not odd, e.g. immutability of tuples, iterator behaviour or modifying collections during iteration. ————————————————————————————————————— Somewhat related video: ▶ this video
in “Python Oddities” · View on HN