1. Why I Invented Python EuroPython – June 27, 2005 Guido van Rossum Elemental Security, Inc. guido@elementalsecurity.com guido@python.org

2. June 27, 2005© 2005 Guido van Rossum 2 About 30 Years Ago... Discovered computers and programming Learned Algol-60, Fortran and Pascal (in that order!) Enjoyed programming more than anything Wanted better tools, and started creating them Started sharing with others Started learning about other languages

3. June 27, 2005© 2005 Guido van Rossum 3 About 20 Years Ago... Knew C and Unix really well Worked on implementing ABC, a new language Ported it to Mac and PC (DOS) Was really excited by the authors' philosophy Was disappointed by ABC's lack of integration Saw its failure to gain acceptance

4. June 27, 2005© 2005 Guido van Rossum 4 About 15 Years Ago... Worked on implementing Amoeba, a new OS Found it needed a scripting language "To bridge the gap between shell and C" Wanted ABC's elegance in that scripting language Had some time on my hands Had some ideas on language implementation

5. June 27, 2005© 2005 Guido van Rossum 5 Python's Birth Xmas 1989 About two weeks of time off with no plans Had it all in my head Fat Mac with Lightspeed C on 20 MB hard drive First code: a parser generator Soon followed: a running program!

6. June 27, 2005© 2005 Guido van Rossum 6 Some Design Goals Shell-like (interactive prompt as well as script files) Extensible architecture (create new types) One tool amongst many, work well with others Additional functionality implementable separately Avoid Not-Invented-Here syndrome (borrow freely) Doable as a one-person project (cut some corners)

7. June 27, 2005© 2005 Guido van Rossum 7 Why Object Oriented? One word: extensibility The original design was OO inside and used OO notation for method access, but did not support user-defined classes Method access was generalized to namespaces One unified namespace for everything in a module Each object is a namespace in its own right A module is just another object Name lookup is customized per namespace User-defined classes were added within the first year, but for a long time remained second-class citizens (until new-style classes in Python 2.2)

8. June 27, 2005© 2005 Guido van Rossum 8 Good Things About ABC Five powerful data types: –list, table, tuple, number, text Orthogonality an important principle No limits: values can be as large as fits in memory Numbers represent mathematical values, not bits Powerful string processing built-in No type declarations; assignment creates variables Simple control structures: IF, SELECT, WHILE, FOR Interactive >>> prompt

9. June 27, 2005© 2005 Guido van Rossum 9 Not-so-good Things About ABC Monolithic implementation; hard to add new things Hard to interact with file system Reinvented programming terminology Apostrophe (') in identifiers; UPPERCASE keywords List is unordered multi-set (bag); table is sorted Small strings relatively slow Assignment: PUT expression IN variable No error handling (errors return to >>> prompt) Editing environment too closely integrated Appealed most to people with insufficient computer access; hard to establish "early adopter" community in Unix world due to lack of OS integration

10. June 27, 2005© 2005 Guido van Rossum 10 What I Changed Extensibility an implementation cornerstone Built-in files; other OS functionality in an extension Returned to standard programming terminology Underscore in identifiers; lowercase keywords List has ordering; dictionary is hash table Optimize for small strings (memcpy is very fast) Assignment: variable = expression Added exceptions, try/except, try/finally (Modula 3) Dropped the integrated editing environment Appealed to the Unix world: imitate /bin/sh behavior, # for comments, support #!, access most low-level Unix system calls (but also PC/Mac ports!)

11. June 27, 2005© 2005 Guido van Rossum 11 What Else I Changed Much of this was motivated by keeping it simple enough to be a one-person project! Dropped type inference; dynamic typing instead Dropped "refinement" control structures Separated int, long and float numeric types Biggest mistakes: –32-bit integers (premature optimization) –int/int truncating the value (mindlessly copied C) –class/type dichotomy (user-classes an afterthought) –string exceptions (exceptions came before classes!)

12. June 27, 2005© 2005 Guido van Rossum 12 The Zen of Python 1.Beautiful is better than ugly. 2.Explicit is better than implicit. 3.Simple is better than complex. 4.Complex is better than complicated. 5.Flat is better than nested. 6.Sparse is better than dense. 7.Readability counts. 8.Special cases aren't special enough to break the rules. 9.Although practicality beats purity. 10.Errors should never pass silently. 11.Unless explicitly silenced. 12.In the face of ambiguity, refuse the temptation to guess. 13.There should be one and preferably only one obvious way to do it. 14.Although that way may not be obvious at first unless you're Dutch. 15.Now is better than never. 16.Although never is often better than right now. 17.If the implementation is hard to explain, it's a bad idea. 18.If the implementation is easy to explain, it may be a good idea. 19.Namespaces are one honking great idea let's do more of those! (a poem by Tim Peters)

13. June 27, 2005© 2005 Guido van Rossum 13 Question Time