The Evolution of Python Juha Helminen 10.11.2009 ABC Imperative - PowerPoint PPT Presentation

The Evolution of Python Juha Helminen 10.11.2009

ABC ● Imperative programming language and interactive programming environment ● Developed in the late 70s and early 80s – initially under the name B (not to mix with C's predecessor) ● Leo Geurts, Lambert Meertens, and Steven Pemberton, National Research Institute for Mathematics and Computer Science in the Netherlands (CWI, Centrum voor Wiskunde en Informatica – also Algol 68) ● Focus on creating a language suitable for non- programmers (e.g. physicists, linguists) ● Intended as a replacement for BASIC as a teaching language and environment

ABC Features ● Statement nesting with indentation - however, no nested scoping, only top/single-level functions ● No variable declarations, static typing, type inference [18] ● No file I/O - persistent global variables that were automatically stored to files ● 5 data types – Numbers - floating point + infinite precision integers and fractions – Texts (strings) - unbounded size – Compounds (tuples) – Lists - sorted collections of any one type of items – Tables - associative arrays with any one type of keys, any one type of items (sorted by key)

ABC Example Function words finds the set of words in a 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

Problems with ABC ● Funding withdrawn, few users because of [4] – unconventional terminology threw off more experienced users - more “newbie-friendly” ● Procedure ↔ how to, variable ↔ location – a monolithic implementation that made it hard to add new features – too much emphasis on theoretical performance - tree- based DS algorithms, optimal for asymptotically large collections but not so for small [14] – not enough flexibility in interaction with other software due to oversimplified I/O ● Very monolithic, no concept of a standard library, built-in commands known by the parser and functions integrated in the runtime → closed system, no user participation

Guido van Rossum ● Fresh out of university 1982 - 1986 worked on implementing ABC at National Research Institute for Mathematics and Computer Science in the Netherlands in the Netherlands (CWI) ● 1986 moved on to work on Amoeba, a distributed operating system ● 1989 started implementation of a simple scripting language for the needs of the Amoeba project, based on experiences with ABC ● Python's principal author – Other CWI employees with major involvement: Sjoerd Mullender and Jack Jansen [16]

"I needed something that would run first and foremost on Amoeba ... available on that platform was a port of the Unix V7 shell ; but it was hard to teach it about Amoeba's (at the time) exciting new features." - Guido van Rossum [4] “my initial goal for Python was to serve as a second language for people who were C or C++ programmers, but who had work where writing a C program was just not effective … Bridge the gap between the shell and C.” - Guido van Rossum [5]

"We found that we needed to write a lot of applications to support users, and that writing these in C our productivity was atrocious . This made me want to use something like ABC ... ABC had been designed more as a teaching and data manipulation language, and its capabilities for interacting with the operating system (which we needed) were limited to non-existent by design. … So I set out to come up with a language that made programmers more productive , and if that meant that the programs would run a bit slower, well, that was an acceptable trade-off." - Guido van Rossum [11]

"One, I was working at Centrum voor Wiskunde en Informatica (CWI) as a programmer on the Amoeba distributed operating system, and I was thinking that an interpreted language would be useful for writing and testing administration scripts . Second, I had previously worked on the ABC project, which had developed a programming language intended for non- technical users. I still had some interesting ideas left over from ABC, and wanted to use them." - Guido van Rossum [12] "I had a number of gripes about the ABC language, but also liked many of its features. It was impossible to extend the ABC language (or its implementation) to remedy my complaints -- in fact its lack of extensibility was one of its biggest problems” - Guido van Rossum [13]

"ABC was designed as a diamond - perfect from the start, but impossible to change . I realized that this had accidentally closed off many possible uses, such as interacting directly with the operating system: ABC's authors had a very low opinion of operating systems , and wanted to shield their users completely from all their many bizarre features" - Guido van Rossum [11]

One-Person Project [14] ● No official budget → needed results quickly ● Borrow as much ideas whenever it makes sense ● “Things should be as simple as possible, but no simpler” ● Do one thing well (“The UNIX Philosophy”) ● Plan to optimize later ● Don't fight the environment and go with the flow ● Don't try for perfection because “good enough” is often just that ● It's okay to cut corners sometimes, especially if you can do it right later

Design Guidelines [14] ● Not tied to a particular platform – it's okay if some functionality is not always available but the core should work everywhere ● Don't bother users with detail the machine can handle ● Encourage platform-independent code but do not cut off access to platform capabilities (c.f. Java) ● Multiple levels of extensibility ● Errors should not be fatal as long as the virtual machine is still functional – errors should neither pass silently ● A bug in the user’s Python code should not be allowed to lead to undefined behavior of the Python interpreter; a core dump is never the user’s fault.

Birth of Python ● First public release 0.9.0 February 20, 1991 (alt.sources) – an interpreted, interactive object-oriented programming language with dynamic typing – virtual machine, parser, and runtime written in C ● Features – indentation used for statement grouping (instead of begin-end or braces) – powerful built-in data types: hash table (dictionary), list (variable-length array), string, number – classes with inheritance – exception handling – extensible - Python and C modules – C modules could make new types available

Python Implementation [19] ● In C as a stack-based byte code interpreter with a collection of primitive types also implemented in C ● The underlying architecture uses “objects” throughout implemented using structures and function pointers ● User-defined objects – objects represented by a new kind of built-in object that stored a class reference pointing to a "class object" shared by all instances of the same class, and a dictionary, dubbed the "instance dictionary" that contained the instance variables – the set of methods of a class were stored in a dictionary whose keys are the method names – classes “first-class objects”, which are easily introspected at run time, it also makes it possible to modify a class dynamically

"We'll provide a bunch of built-in object types , such as dictionaries, lists, the various kinds of numbers, and strings, to the language. But we'll also make it easy for third-party programmers to add their own object types to the system." - Guido van Rossum

Python Example - indentation, no declarations, colon starts a block >>> def select_max(a,b): ... if a < b: ... max=b ... else: ... max = a ... return max ... >>> max_value = select_max(1,2) >>> print 'Max is', max_value Max is 2 >>>

Python Example - class definition, instantiation and attribute access – explicit receiver/passed implicitly instead of a new keyword >>> class A: ... def __init__(self, x): ... self.x = x ... def spam(self, y): ... print self.x, y ... >>> inst = A(5) >>> inst.x 5 >>> inst.spam(6) 5 6

Python Example - built-in data types, initialization with literal values, tuple unpacking, slicing >>> tuple = (1,2,3) >>> list = [1,2,3] >>> hash = {1:'a', 2:'b', 3:'c'} >>> a,b,c = tuple >>> a 1 >>> a,b = b,a >>> a 2 >>> b 1 >>> list[0:1] [1] >>> hash[2] 'b'

Zen of Python by Tim Peters [15] ● 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.

Zen of Python by Tim Peters [15] ● 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!