HackerTube

How Python was Shaped by leaky Internals, Armin Ronacher, Flask framework

Видео с мероприятий {speach!15 HN recommenders · recommended in 16 months, 2017–2025
YouTube
talk · advanced · evergreen · 2017–2025 on HN

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.

12 comments from Hacker News

@fault12022-01 · in “Faster CPython (2021) [pdf]”

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

Strongly recommends View on HN
@haberman2021-11 · in “Pyjion – A Python JIT Compiler”

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.

Strongly recommends View on HN
@haberman2021-09 · in “Writing Python Extensions in Assembly”

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.

Strongly recommends View on HN
@arc7762020-10 · in “Attempts to make Python fast”

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

Strongly recommends View on HN
@nerdponx2020-09 · in “Python's Innards: Introduction (2010)”

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

Strongly recommends View on HN