A Python for Future Generations

A Python for Future Generations

Keynote at EuroPython 2017 in Rimini.

181de1fb11dffe39774f3e2e23cda3b6?s=128

Armin Ronacher

July 10, 2017
Tweet

Transcript

  1. A Python for Future Generations Armin @mitsuhiko 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 twitter.com/@mitsuhiko

    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. pypy, jython all copy the quirks because

  22. they want high compatibility because

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

    because
  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 • we're moving away from setup.py install

    • pip is a separate tool • wheels • multi-version would require metadata access where are we now?
  60. packaging and modules • we can steal from others •

    can target python 3 only if needed realistic change?
  61. language standard

  62. language standard • javascript: clarify interpreter behavior • simplified language

    subset? • generally leaner language? • more oversight over language development
  63. language standard • maybe micropython and other things can lead

    the way • community can kill extension modules for CFFI realistic change?
  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 • we would need to kill string

    slicing • utf-8 everywhere is straightforward • kill surrogate-escapes for a real os string? realistic change?
  68. extension modules

  69. extension modules more cffi less libpython

  70. extension modules • tricky for things like numpy • generally

    possible for many uses realistic change?
  71. linters & type annotations

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

  73. linters & type annotations rustfmt, gofmt, prettier, …

  74. linters & type annotations • maybe? • typing in Python

    3 might go this way realistic change?
  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. QA &