Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
A Python for Future Generations
Search
Armin Ronacher
July 10, 2017
Programming
20
9.3k
A Python for Future Generations
Keynote at EuroPython 2017 in Rimini.
Armin Ronacher
July 10, 2017
Tweet
Share
More Decks by Armin Ronacher
See All by Armin Ronacher
Agentic Coding: The Future of Software Development with Agents
mitsuhiko
0
110
Do Dumb Things
mitsuhiko
0
630
No Assumptions
mitsuhiko
0
180
The Complexity Genie
mitsuhiko
0
210
The Catch in Rye: Seeding Change and Lessons Learned
mitsuhiko
0
330
Runtime Objects in Rust
mitsuhiko
0
360
Rust at Sentry
mitsuhiko
0
470
Overcoming Variable Payloads to Optimize for Performance
mitsuhiko
0
220
Rust API Design Learnings
mitsuhiko
0
560
Other Decks in Programming
See All in Programming
たった 1 枚の PHP ファイルで実装する MCP サーバ / MCP Server with Vanilla PHP
okashoi
1
270
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
790
Node-RED を(HTTP で)つなげる MCP サーバーを作ってみた
highu
0
120
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
1
6.1k
0626 Findy Product Manager LT Night_高田スライド_speaker deck用
mana_takada
0
180
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
2
150
『自分のデータだけ見せたい!』を叶える──Laravel × Casbin で複雑権限をスッキリ解きほぐす 25 分
akitotsukahara
2
640
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
530
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
270
RailsGirls IZUMO スポンサーLT
16bitidol
0
190
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
140
猫と暮らす Google Nest Cam生活🐈 / WebRTC with Google Nest Cam
yutailang0119
0
150
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
KATA
mclloyd
30
14k
Scaling GitHub
holman
460
140k
4 Signs Your Business is Dying
shpigford
184
22k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Designing for Performance
lara
610
69k
GraphQLとの向き合い方2022年版
quramy
49
14k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Transcript
A Python for Future Generations Armin @mitsuhiko Ronacher
Hi, I'm Armin ... and I do Open Source, lots
of Python and SaaS Flask Sentry …
… and here is where you can find me twitter.com/@mitsuhiko
github.com/mitsuhiko lucumr.pocoo.org/
‘raising awareness’
the grass is always greener somewhere
… what's Python anyway?
Python is whatever cpython does
behavior & stdlib
a + b = ?
a.__add__(b) ?
type(a).__add__(a, b) ?
a.__class__.__add__(a, b) ?
they are all not necessarily correct
1 0 LOAD_FAST 0 (a) 3 LOAD_FAST 1 (b) 6
BINARY_ADD
which is “obj as num”.add or “obj as sequence”.concat
gave us unclear behavior when subclassing builtins
there is no “+” operator
there is PyNumber_Add and PySequence_Concat
does it matter?
debatable but … kinda?
pypy, jython all copy the quirks because
they want high compatibility because
users would not use it if it was not compatible
because
prevents more innovative language changes
Python in 30 Years?
make the python we use more like the python we
teach
it's a common story
python developers value compatibility
distutils implements original setup.py
setuptools monkey patches distutils to support Python eggs
pip monkey patches setuptools on the fly to manage python
packages
wheel monkey patches setuptools to build wheels instead of eggs
cffi monkey patches setuptools and distutils to build extensions
snaek monkey patches cffi to build Rust extension modules
the GIL
the only reason removing the GIL is hard is backwards
compatibility
looks like we're not good at breaking compatibility
our only attempt was both radical and not radical enough
future of “scripting” languages
they are here to stay
but they will look different
standards + ecosystem
if we want to be here in 30 years, we
need to evolve
where we did well
interpreter code is readable
ease of compilation
extensibility
flat dependency chains
runtime introspection
what we should probably do
easier and clearer language behavior
looking elsewhere
JavaScript
Rust
both are new and modern both learned from mistakes
packaging and modules
packaging and modules package.json Cargo.toml
packaging and modules • metadata is runtime available • by
default no code execution on installation • (optionally) multiple versions per library • public vs private / peer dependencies
packaging and modules • we're moving away from setup.py install
• pip is a separate tool • wheels • multi-version would require metadata access where are we now?
packaging and modules • we can steal from others •
can target python 3 only if needed realistic change?
language standard
language standard • javascript: clarify interpreter behavior • simplified language
subset? • generally leaner language? • more oversight over language development
language standard • maybe micropython and other things can lead
the way • community can kill extension modules for CFFI realistic change?
unicode
unicode utf-8 everywhere wtf-8 where needed
unicode • very little guessing • rust: operating system string
type • rust: free from utf-8 to os-string and bytes • explicit unicode character APIs • emojis mean no basic plane
packaging and modules • we would need to kill string
slicing • utf-8 everywhere is straightforward • kill surrogate-escapes for a real os string? realistic change?
extension modules
extension modules more cffi less libpython
extension modules • tricky for things like numpy • generally
possible for many uses realistic change?
linters & type annotations
linters & type annotations babel, eslint, … typescript, flow, …
linters & type annotations rustfmt, gofmt, prettier, …
linters & type annotations • maybe? • typing in Python
3 might go this way realistic change?
what you can do!
abuse the language less
sys._getframe(N).f_locals['_wat'] = 42
class X(dict):
stop writing non cffi extensions
stop being clever with sys.modules
awareness is the first step
QA &