A Python for Future Generations Armin @mitsuhiko Ronacher Hi, I'm - - PowerPoint PPT Presentation

▶
a python for future generations
SMART_READER_LITE
LIVE PREVIEW

A Python for Future Generations Armin @mitsuhiko Ronacher Hi, I'm - - PowerPoint PPT Presentation

Dec 20, 2023 432 likes •1.27k views

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 twi tu er.com/@mitsuhiko where you github.com/mitsuhiko can find me

slide-1
SLIDE 1

A Python for Future Generations

Armin @mitsuhiko Ronacher

slide-2
SLIDE 2

Hi, I'm Armin

... and I do Open Source, lots of Python and SaaS Flask Sentry …

slide-3
SLIDE 3

… and here is where you can find me

twituer.com/@mitsuhiko github.com/mitsuhiko lucumr.pocoo.org/

slide-4
SLIDE 4

‘raising awareness’

slide-5
SLIDE 5

the grass is always greener somewhere

slide-6
SLIDE 6

… what's Python anyway?

slide-7
SLIDE 7

Python is whatever cpython does

slide-8
SLIDE 8

behavior & stdlib

slide-9
SLIDE 9

a + b = ?

slide-10
SLIDE 10

a.__add__(b) ?

slide-11
SLIDE 11

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

slide-12
SLIDE 12

a.__class__.__add__(a, b) ?

slide-13
SLIDE 13

they are all not necessarily correct

slide-14
SLIDE 14

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

slide-15
SLIDE 15

which is “obj as num”.add

  • r “obj as sequence”.concat
slide-16
SLIDE 16

gave us unclear behavior when subclassing builtins

slide-17
SLIDE 17

there is no “+” operator

slide-18
SLIDE 18

there is PyNumber_Add and PySequence_Concat

slide-19
SLIDE 19

does it matuer?

slide-20
SLIDE 20

debatable but … kinda?

slide-21
SLIDE 21

pypy, jython all copy the quirks

because

slide-22
SLIDE 22

they want high compatibility

because

slide-23
SLIDE 23

users would not use it if it was not compatible

because

slide-24
SLIDE 24

prevents more innovative language changes

slide-25
SLIDE 25

Python in 30 Years?

slide-26
SLIDE 26

make the python we use more like the python we teach

slide-27
SLIDE 27

it's a common story

slide-28
SLIDE 28

python developers value compatibility

slide-29
SLIDE 29

distutils

implements original setup.py

slide-30
SLIDE 30

setuptools

monkey patches distutils to support Python eggs

slide-31
SLIDE 31

pip

monkey patches setuptools on the fly to manage python packages

slide-32
SLIDE 32

wheel

monkey patches setuptools to build wheels instead of eggs

slide-33
SLIDE 33

cffi

monkey patches setuptools and distutils to build extensions

slide-34
SLIDE 34

snaek

monkey patches cffi to build Rust extension modules

slide-35
SLIDE 35

the GIL

slide-36
SLIDE 36

the only reason removing the GIL is hard is backwards compatibility

slide-37
SLIDE 37

looks like we're not good at breaking compatibility

slide-38
SLIDE 38
  • ur only attempt was

both radical and not radical enough

slide-39
SLIDE 39

future of “scripting” languages

slide-40
SLIDE 40

they are here to stay

slide-41
SLIDE 41

but they will look different

slide-42
SLIDE 42

standards + ecosystem

slide-43
SLIDE 43

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

slide-44
SLIDE 44

where we did well

slide-45
SLIDE 45

interpreter code is readable

slide-46
SLIDE 46

ease of compilation

slide-47
SLIDE 47

extensibility

slide-48
SLIDE 48

flat dependency chains

slide-49
SLIDE 49

runtime introspection

slide-50
SLIDE 50

what we should probably do

slide-51
SLIDE 51

easier and clearer language behavior

slide-52
SLIDE 52

looking elsewhere

slide-53
SLIDE 53

JavaScript

slide-54
SLIDE 54

Rust

slide-55
SLIDE 55

both are new and modern both learned from mistakes

slide-56
SLIDE 56

packaging and modules

slide-57
SLIDE 57

packaging and modules

package.json Cargo.toml

slide-58
SLIDE 58

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

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

packaging and modules

  • we can steal from others
  • can target python 3 only if needed

realistic change?

slide-61
SLIDE 61

language standard

slide-62
SLIDE 62

language standard

  • javascript: clarify interpreter behavior
  • simplified language subset?
  • generally leaner language?
  • more oversight over language development
slide-63
SLIDE 63

language standard

  • maybe micropython and other things can lead

the way

  • community can kill extension modules for CFFI

realistic change?

slide-64
SLIDE 64

unicode

slide-65
SLIDE 65

unicode

utf-8 everywhere wtf-8 where needed

slide-66
SLIDE 66

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

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

extension modules

slide-69
SLIDE 69

extension modules

more cffi less libpython

slide-70
SLIDE 70

extension modules

  • tricky for things like numpy
  • generally possible for many uses

realistic change?

slide-71
SLIDE 71

linters & type annotations

slide-72
SLIDE 72

linters & type annotations

babel, eslint, … typescript, flow, …

slide-73
SLIDE 73

linters & type annotations

rustfmt, gofmt, prettier, …

slide-74
SLIDE 74

linters & type annotations

  • maybe?
  • typing in Python 3 might go this way

realistic change?

slide-75
SLIDE 75

what you can do!

slide-76
SLIDE 76

abuse the language less

slide-77
SLIDE 77

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

slide-78
SLIDE 78

class X(dict):

slide-79
SLIDE 79

stop writing non cffi extensions

slide-80
SLIDE 80

stop being clever with sys.modules

slide-81
SLIDE 81

awareness is the first step

slide-82
SLIDE 82

QA

&