Slide 1

Slide 1 text

A Python for Future Generations Armin @mitsuhiko Ronacher

Slide 2

Slide 2 text

Hi, I'm Armin ... and I do Open Source, lots of Python and SaaS Flask Sentry …

Slide 3

Slide 3 text

… and here is where you can find me twitter.com/@mitsuhiko github.com/mitsuhiko lucumr.pocoo.org/

Slide 4

Slide 4 text

‘raising awareness’

Slide 5

Slide 5 text

the grass is always greener somewhere

Slide 6

Slide 6 text

… what's Python anyway?

Slide 7

Slide 7 text

Python is whatever cpython does

Slide 8

Slide 8 text

behavior & stdlib

Slide 9

Slide 9 text

a + b = ?

Slide 10

Slide 10 text

a.__add__(b) ?

Slide 11

Slide 11 text

type(a).__add__(a, b) ?

Slide 12

Slide 12 text

a.__class__.__add__(a, b) ?

Slide 13

Slide 13 text

they are all not necessarily correct

Slide 14

Slide 14 text

1 0 LOAD_FAST 0 (a) 3 LOAD_FAST 1 (b) 6 BINARY_ADD

Slide 15

Slide 15 text

which is “obj as num”.add or “obj as sequence”.concat

Slide 16

Slide 16 text

gave us unclear behavior when subclassing builtins

Slide 17

Slide 17 text

there is no “+” operator

Slide 18

Slide 18 text

there is PyNumber_Add and PySequence_Concat

Slide 19

Slide 19 text

does it matter?

Slide 20

Slide 20 text

debatable but … kinda?

Slide 21

Slide 21 text

pypy, jython all copy the quirks because

Slide 22

Slide 22 text

they want high compatibility because

Slide 23

Slide 23 text

users would not use it if it was not compatible because

Slide 24

Slide 24 text

prevents more innovative language changes

Slide 25

Slide 25 text

Python in 30 Years?

Slide 26

Slide 26 text

make the python we use more like the python we teach

Slide 27

Slide 27 text

it's a common story

Slide 28

Slide 28 text

python developers value compatibility

Slide 29

Slide 29 text

distutils implements original setup.py

Slide 30

Slide 30 text

setuptools monkey patches distutils to support Python eggs

Slide 31

Slide 31 text

pip monkey patches setuptools on the fly to manage python packages

Slide 32

Slide 32 text

wheel monkey patches setuptools to build wheels instead of eggs

Slide 33

Slide 33 text

cffi monkey patches setuptools and distutils to build extensions

Slide 34

Slide 34 text

snaek monkey patches cffi to build Rust extension modules

Slide 35

Slide 35 text

the GIL

Slide 36

Slide 36 text

the only reason removing the GIL is hard is backwards compatibility

Slide 37

Slide 37 text

looks like we're not good at breaking compatibility

Slide 38

Slide 38 text

our only attempt was both radical and not radical enough

Slide 39

Slide 39 text

future of “scripting” languages

Slide 40

Slide 40 text

they are here to stay

Slide 41

Slide 41 text

but they will look different

Slide 42

Slide 42 text

standards + ecosystem

Slide 43

Slide 43 text

if we want to be here in 30 years, we need to evolve

Slide 44

Slide 44 text

where we did well

Slide 45

Slide 45 text

interpreter code is readable

Slide 46

Slide 46 text

ease of compilation

Slide 47

Slide 47 text

extensibility

Slide 48

Slide 48 text

flat dependency chains

Slide 49

Slide 49 text

runtime introspection

Slide 50

Slide 50 text

what we should probably do

Slide 51

Slide 51 text

easier and clearer language behavior

Slide 52

Slide 52 text

looking elsewhere

Slide 53

Slide 53 text

JavaScript

Slide 54

Slide 54 text

Rust

Slide 55

Slide 55 text

both are new and modern both learned from mistakes

Slide 56

Slide 56 text

packaging and modules

Slide 57

Slide 57 text

packaging and modules package.json Cargo.toml

Slide 58

Slide 58 text

packaging and modules • metadata is runtime available • by default no code execution on installation • (optionally) multiple versions per library • public vs private / peer dependencies

Slide 59

Slide 59 text

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?

Slide 60

Slide 60 text

packaging and modules • we can steal from others • can target python 3 only if needed realistic change?

Slide 61

Slide 61 text

language standard

Slide 62

Slide 62 text

language standard • javascript: clarify interpreter behavior • simplified language subset? • generally leaner language? • more oversight over language development

Slide 63

Slide 63 text

language standard • maybe micropython and other things can lead the way • community can kill extension modules for CFFI realistic change?

Slide 64

Slide 64 text

unicode

Slide 65

Slide 65 text

unicode utf-8 everywhere wtf-8 where needed

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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?

Slide 68

Slide 68 text

extension modules

Slide 69

Slide 69 text

extension modules more cffi less libpython

Slide 70

Slide 70 text

extension modules • tricky for things like numpy • generally possible for many uses realistic change?

Slide 71

Slide 71 text

linters & type annotations

Slide 72

Slide 72 text

linters & type annotations babel, eslint, … typescript, flow, …

Slide 73

Slide 73 text

linters & type annotations rustfmt, gofmt, prettier, …

Slide 74

Slide 74 text

linters & type annotations • maybe? • typing in Python 3 might go this way realistic change?

Slide 75

Slide 75 text

what you can do!

Slide 76

Slide 76 text

abuse the language less

Slide 77

Slide 77 text

sys._getframe(N).f_locals['_wat'] = 42

Slide 78

Slide 78 text

class X(dict):

Slide 79

Slide 79 text

stop writing non cffi extensions

Slide 80

Slide 80 text

stop being clever with sys.modules

Slide 81

Slide 81 text

awareness is the first step

Slide 82

Slide 82 text

QA &