A Python for Future Generations. Ronacher

Transcription

1 A Python for Future Generations Ronacher

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

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

4 raising awareness

5 the grass is always greener somewhere

6 what's Python anyway?

7 Python is whatever cpython does

8 behavior & stdlib

9 a + b =?

10 a. add (b)?

11 type(a). add (a, b)?

12 a. class. add (a, b)?

13 they are all not necessarily correct

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

15 which is obj as num.add or obj as sequence.concat

16 gave us unclear behavior when subclassing builtins

17 there is no + operator

18 there is PyNumber_Add and PySequence_Concat

19 does it matter?

20 debatable but kinda?

21 because pypy, jython all copy the quirks

22 because they want high compatibility

23 because users would not use it if it was not compatible

24 prevents more innovative language changes

25 Python in 30 Years?

26 make the python we use more like the python we teach

27 it's a common story

28 python developers value compatibility

29 distutils implements original setup.py

30 setuptools monkey patches distutils to support Python eggs

31 pip monkey patches setuptools on the fly to manage python packages

32 wheel monkey patches setuptools to build wheels instead of eggs

33 cffi monkey patches setuptools and distutils to build extensions

34 snaek monkey patches cffi to build Rust extension modules

35 the GIL

36 the only reason removing the GIL is hard is backwards compatibility

37 looks like we're not good at breaking compatibility

38 our only attempt was both radical and not radical enough

39 future of scripting languages

40 they are here to stay

41 but they will look different

42 standards + ecosystem

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

44 where we did well

45 interpreter code is readable

46 ease of compilation

47 extensibility

48 flat dependency chains

49 runtime introspection

50 what we should probably do

51 easier and clearer language behavior

52 looking elsewhere

53 JavaScript

54 Rust

55 both are new and modern both learned from mistakes

56 packaging and modules

57 packaging and modules package.json Cargo.toml

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

59 packaging and modules where are we now? we're moving away from setup.py install pip is a separate tool wheels multi-version would require metadata access

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

61 language standard

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

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

64 unicode

65 unicode utf-8 everywhere wtf-8 where needed

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

67 packaging and modules realistic change? we would need to kill string slicing utf-8 everywhere is straightforward kill surrogate-escapes for a real os string?

68 extension modules

69 extension modules more cffi less libpython

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

71 linters & type annotations

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

73 linters & type annotations rustfmt, gofmt, prettier,

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

75 what you can do!

76 abuse the language less

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

78 class X(dict):

79 stop writing non cffi extensions

80 stop being clever with sys.modules

81 awareness is the first step

82 Q A &