Python has four main pain points: speed, scalability, type safety, and adherence to the CPython implementation. It discusses how Python could potentially be improved by applying techniques from other languages to increase speed, removing the global interpreter lock to improve scalability, using static type analysis tools and annotations to increase type safety, and developing higher-level tools for writing extensions to improve portability across implementations. Overall, the document analyzes potential issues with the Python language and explores possible solutions.

1. Four Python Pains
Stefane Fermigier
Scripting Languages Workshop, IRILL, May 2011

2. Part1: Some context

10. Wrong
(on several points)

11. Python
(“Scripting Language”)
• Has built-in syntactical support for arbitrarily
complex data structures (lists, dictionaries)
• Supports significantly complex applications:
ERP5, Plone, Nuxeo CPS (~320 KLOC),
OpenERP (~150 KLOC), Komodo (~250
KLOC)
• Is compiled (to bytecode)

12. Scala
(“Sys. Prog. Language”)
• Is interpreted (it as a REPL)
• Is a high-level language - in other words, has a
high CPU instructions / statement ratio
(comparable or higher than Python)

13. Other counterexamples
• Java, pre-generics (Java SE < 5, i.e. at the time
of Ousterhout’s paper), had really weak
support for static typing
• Clojure (that many consider in the same
league as Scala) is not even statically typed

16. At which expense?

17. • Execution speed?
• Safety?
• Maintainability?
• What else?

18. Or maybe Python is a
scripting language after all ?

19. Uses of Python
• Education
• Small to medium sized sysadmin and
software engineering project
• Medium to large web frameworks (Zope,
Django...) and applications (Youtube...)
• Scientific computing (numpy, scipy...)
• Scripting of games, desktop apps, etc.

20. Recap: 4 pain points
• Speed
• Scalability
• Type-safety
• Adherence to external code bases, and an
implementation (CPython)

21. Part 2: Discussion

22. Speed
• Python (seems to be) slower by 10x than
Clojure and V8 (JavaScript)
• Both Clojure and JavaScript are dynamically
typed languages
• TODO: look at Clojure and V8 and see
how they do it

24. Scalability
• CPython multi-threading / multi-core
performance is constrained by “the GIL” (global
interpretor lock)
• It doesn’t have to be there (Jython doesn’t have
one) but removing it from Python is
controversial
• Python has support for some par prog
constructs (see: http://wiki.python.org/moin/
ParallelProcessing) but not the fancy new ones
(a la Scala, Clojure, Go, etc.)

26. Type Safety
• Static typic is good to create safer programs,
and also to ease refactoring (necessary
condition for agility)
• Since Python 3, type annotations are possible
on variables, parameters, etc.
• Some tools (e.g. Jetbrains’ PyCharm) have
support for type inference on Python, and
enable: code completion, errors detections,
refactoring...

28. Adherence to CPython
• There are at least 4 major Python
implementations: CPython, Jython, IronPython
and PyPy
• But only CPython is mainstream
• Why? Because all the “system programming
lang” extensions written for CPython cannot
be used with the others
• And we’re talking about hundreds of packages

29. Solution?
• There are also tools, languages and
extensions that ease up the task of writing a
CPython extension: SWIG, ctypes, Pyrex,
Cython...
• By encapsulating part of the complexity and
low-level details of creating a Python
extension, it could make is both easier, more
robust and easier to share extensions
between language implementations

30. Conclusion

31. • Python could maybe be made 10x faster by
applying ideas from Clojure and V8
• Python could be made more scalable by
removing the GIL (probably needs to
rewrite the interpreter, though) and adding
modern parallel programming paradigms

32. • Python programs could be made more
robust with the help of static typing analysis
tools + a little help from the developers
(i.e. add a few type annotations in their
programs and libraries)
• Python is a scripting language after all (but
not only), and could benefit from a way of
writing extensions that is higher level than
the common one (but then: how to convert
the existing code base?)