Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Sign up for free
A Python for Future Generations
July 10, 2017
A Python for Future Generations
Keynote at EuroPython 2017 in Rimini.
July 10, 2017
More Decks by Armin Ronacher
See All by Armin Ronacher
We gave a Mouse an NDK
Debug is the new Release
A Future Python
Failing in Rust
Rust at Sentry
My Python is Rusting
Pragmantic SaaS Architecture
A Practical Road to SaaS' in Python
Rust for Serious Developers
Other Decks in Programming
See All in Programming
Kotlin 最新動向2022 #tfcon #techfeed
Update from the Elixir team - 2022
Language Summit 2022: WebAssembly: Python in the browser and beyond
Yumemi.apk #6 ～ゆめみのAndroidエンジニア 日頃の成果大発表会！～ Session 2
Loom is Blooming
See All Featured
Rails Girls Zürich Keynote
Ruby is Unlike a Banana
GitHub's CSS Performance
jQuery: Nuts, Bolts and Bling
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
Imperfection Machines: The Place of Print at Facebook
The Invisible Side of Design
No one is an island. Learnings from fostering a developers community.
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
How GitHub (no longer) Works
Building Better People: How to give real-time feedback that sticks.
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 ﬁnd me twitter.com/@mitsuhiko
the grass is always greener somewhere
… what's Python anyway?
Python is whatever cpython does
behavior & stdlib
a + 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
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
prevents more innovative language changes
Python in 30 Years?
make the python we use more like the python we
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 ﬂy to manage python
wheel monkey patches setuptools to build wheels instead of eggs
cﬃ monkey patches setuptools and distutils to build extensions
snaek monkey patches cfﬁ to build Rust extension modules
the only reason removing the GIL is hard is backwards
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
ﬂat dependency chains
what we should probably do
easier and clearer language behavior
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?
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 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 more cfﬁ 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, ﬂow, …
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
stop writing non cfﬁ extensions
stop being clever with sys.modules
awareness is the ﬁrst step