® ® why design another language? python uk & accu spring conference oxford - april 2, 2003...

®

®

Why Design Another Language?

Python UK & ACCU Spring ConferenceOxford - April 2, 2003

Guido van RossumDirector of PythonLabs at Zope Corporation

guido@python.orgguido@zope.com

3/31/2003 Slide 2 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

3/31/2003 Slide 3 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

Overview

• The birth of a new language

• The Zen of Python

• What does the future hold?

3/31/2003 Slide 4 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

Ancient History: ABC

– late 70s, early 80s at CWI in Amsterdam

– Lambert Meertens, Leo Geurts, Steven Pemberton, and others

– www.cwi.nl/~steven/abc

– original goal: "stamp out BASIC"

– aimed at beginners and non-professionals

– language as well as environment

– 5 powerful data types• number, string, tuple, list, dictionary

– nesting by indentation

– I joined the team to help finish the implementation

3/31/2003 Slide 5 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

ABC Example

• Define function words to collect the set of all words in document:

HOW TO RETURN words document: PUT {} IN collection FOR line IN document: FOR word IN split line: IF word not.in collection: INSERT word IN collection RETURN collection

3/31/2003 Slide 6 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

Python Equivalent

def words(file): "Set of all words in a file." words = {} # dict used as set for line in file: for word in line.split(): words[word] = 1 return words.keys()

3/31/2003 Slide 7 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

ABC's Strengths

– interactive

– structured programming support• no "goto"

– orthogonal design (hence easy to learn)• small number of powerful constructs

– abstraction away from hardware quirks• no 16/32-bit limits on numbers, object sizes

• no files (!?)

– data types designed after task analysis

– static typing (without declarations!)

3/31/2003 Slide 8 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

ABC's Downfall

– reinventing terminology

– poor integration with OS• no "file" concept

– hard to extend/adapt• monolithic implementation

• interactive environment tightly integrated

– hard to find users• beginners didn't have computers

• experts put off by non-standard approach

• no internet or www, only uucp/usenet

3/31/2003 Slide 9 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

Fast Forward to 1989

– needed a scripting language for Amoeba

– existing languages found wanting

– fondly remembered ABC

– audience: C programmers

– goal: bridge gap between shell and C

– time available

– enjoyed Monty Python reruns :-)

– other influences: Modula-3, C/C++• and even Smalltalk, Icon, Pascal, Algol-68

3/31/2003 Slide 10 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

ABC's Influences

– interactivity (but as an option!)

– nesting by indentation

– abstraction away from hardware

– structured programming

– data type design• containers, immutability

– many string operations

– [raw_]input(), has_key(), print, ``

– reference-counted memory allocation

3/31/2003 Slide 11 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

ABC's Anti-Influences

– extensible implementation design

– good integration with OS environments

– favor simplicity and practicality• may compromise purity and abstractions

– dynamic instead of static typing (!!)

– replaced ABC's sorting lists and tables• order-preserving lists and hash tables instead

– separate int and long types (a mistake!)

– no rational numbers

– object instead of value semantics

3/31/2003 Slide 12 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

Influences from C

– zero-based indexing

– lexical definitions of most tokens• numbers, strings, identifiers

– return, break, continue

– expression operators

– standard I/O library

– assignment syntax• much later: augmented assignments

– anti-influence (amongst many others):• no assignment in expressions

3/31/2003 Slide 13 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

Other Influences

– Modula-3, via DEC SRC's Modula 2+:• modules, import, from/import

• exceptions: raise, try/execpt, try/finally

• method/function equivalence (explicit self)

• marshalling / pickling (data serialization)

– Smalltalk: dynamic typing, bytecode

– C++: operator overloading

– Icon, Algol-68: slice notation

– Pascal: ord(), chr()

– Shell: # comment (for #! convenience)

3/31/2003 Slide 14 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

Other Anti-Influences

• Perl (as it was in 1989; Perl 3?)– Unix-specific (no hope of Amoeba port)

– too much magic

– focus on text processing• useful, but not what I needed

– data types not well thought-out• (try creating a hash of hashes)

• Pascal: structure by nested functions

• Lisp: lack of syntax

3/31/2003 Slide 15 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

Python's Success

– being at the right place at the right time

– user feedback taken seriously

– open source license

– does one (fairly large :-) thing well

– cross-platform portability

– integrates well in any OS environment

– writing extensions is easy (enough)

– "batteries included" standard library

– and... the Zen of Python

3/31/2003 Slide 16 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

The Zen of Python - part 1 of 2

(Formulated by Tim Peters)

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.

3/31/2003 Slide 17 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

The Zen of Python - part 2 of 2

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!

3/31/2003 Slide 18 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

What Next?

• Python is successful– to remain so, it needs to evolve

– while being careful not to break things!

• Compatibility endangers elegance– cruft accumulates over years

• I'm no fan of grand redesign– second system syndrome

– easy to lose emergent qualities

3/31/2003 Slide 19 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

The Plan: Focused Evolution

• Python 3000:– idealized, utopian target

– hard to imagine (too far away)

• Python 3.0:– next big step; new stuff replaces cruft

– some incompatibilities allowed

• Python 2.3, 2.4, 2.5, ...:– each step (nearly) compatible

– deprecate cruft in 2.x, remove in 2. x+1

3/31/2003 Slide 20 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

Python 3000

– Paul Graham's "100-year language"?

– my vision of Python 3000 is changing

– broadened scope:• reaches higher and lower levels

• compiles to machine code as needed

• extensive standard library

• optional interfaces and type declarations

• compiler warns about likely bugs

• design your own domain-specific language

3/31/2003 Slide 21 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

Python 3.0

– three years from now (ambitious)

– complete "big deprecations"• int/int will return float

• string module gone

• classic classes gone

– new standard I/O implementation

– use more iterators and generators• range() becomes iterator factory

– tweak rules for better code generation• so compiler can recognize builtin names

3/31/2003 Slide 22 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

Python 2.3

– first beta in two weeks

– final release June or July this year

– conservative release• no syntactic changes

• lots of library additions

• performance tuned up

• many bugs fixed

3/31/2003 Slide 23 ©2003 Zope® Corporation and Python Software Foundation. All Rights Reserved.

®

®

Python Software Foundation

– US non-profit organization

– www.python.org/psf

– donations benefit Python development

– beginning major fund-raising• Python 3.0 needs resources