HackerTube.dev

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

Видео с мероприятий {speach! · 20.1K views · 2016-07-13 · 49:55

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

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.

On Hacker News

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.

Recommended by 15 HN people across 16 months · HN mentions 2017–2025

Topics

Python, Ruby & scripting languagesSoftware performance & optimizationProgramming language design
Search by tags
cpythonperformancejitc apilanguage semanticsarmin ronacher

What people said

fault1 · 2022-01 · Strong recommendation

I thought this presentation by Armin Ronacher (the creator of Flask and Jinja) was very enlightening: How Python was Shaped by leaky Internals(2016): [VIDEO] See also this HN post (Attempts to make Python fast): [LINK]

Read the original HN comment ↗
haberman · 2021-11 · Strong recommendation

I think "a + b" is a good example. I really recommend the talk I linked ( [VIDEO] ), it gets deep into this stuff. I don't think anyone benefits from "a + b" having so many special cases.

Read the original HN comment ↗
haberman · 2021-09 · Strong recommendation

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: [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.

Read the original HN comment ↗

Sources

Video by Видео с мероприятий {speach!, played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources