Why I Invented Python

EuroPython June 27, 2005 Guido van Rossum Elemental Security, Inc.

guido@elementalsecurity.com guido@python.org

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

June 27, 2005

2005 Guido van Rossum

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

June 27, 2005

2005 Guido van Rossum

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

June 27, 2005

2005 Guido van Rossum

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!

June 27, 2005

2005 Guido van Rossum

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)

June 27, 2005

2005 Guido van Rossum

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)
June 27, 2005 2005 Guido van Rossum

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

June 27, 2005

2005 Guido van Rossum

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
June 27, 2005 2005 Guido van Rossum

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!)
June 27, 2005 2005 Guido van Rossum

10

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!)

June 27, 2005

2005 Guido van Rossum

11

The Zen of Python

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

(a poem by Tim Peters)

June 27, 2005 2005 Guido van Rossum

12

Question Time

June 27, 2005

2005 Guido van Rossum

13