| % Format this file with latex. |
| |
| %\documentstyle[11pt,myformat]{article} |
| \documentstyle[palatino,11pt,myformat]{article} |
| |
| \title{\bf |
| Python Tutorial \\ |
| (DRAFT) |
| } |
| |
| \author{ |
| Guido van Rossum \\ |
| Dept. CST, CWI, Kruislaan 413 \\ |
| 1098 SJ Amsterdam, The Netherlands \\ |
| E-mail: {\tt guido@cwi.nl} |
| } |
| |
| \begin{document} |
| |
| \pagenumbering{roman} |
| |
| \maketitle |
| |
| \begin{abstract} |
| |
| \noindent |
| Python is a simple, yet powerful programming language that bridges the |
| gap between C and shell programming, and is thus ideally suited for rapid |
| prototyping. |
| Its syntax is put together from constructs borrowed from a variety of other |
| languages; most prominent are influences from ABC, C, Modula-3 and Icon. |
| |
| The Python interpreter is easily extended with new functions and data |
| types implemented in C. |
| Python is also suitable as an extension language for highly |
| customizable C applications such as editors or window managers. |
| |
| Python is available for various operating systems, amongst which |
| several flavors of \UNIX, Amoeba, and the Apple Macintosh O.S. |
| |
| This tutorial introduces the reader informally to the basic concepts and |
| features of the Python language and system. |
| It helps to have a Python interpreter handy for hands-on experience, |
| but as the examples are self-contained, the tutorial can be read |
| off-line as well. |
| |
| For a description of standard objects and modules, see the Library |
| Reference document. |
| The Language Reference document (XXX not yet existing) |
| gives a more formal definition of the language. |
| |
| \end{abstract} |
| |
| \pagebreak |
| |
| \tableofcontents |
| |
| \pagebreak |
| |
| \pagenumbering{arabic} |
| |
| \section{Whetting Your Appetite} |
| |
| If you ever wrote a large shell script, you probably know this feeling: |
| you'd love to add yet another feature, but it's already so slow, and so |
| big, and so complicated; or the feature involves a system call or other |
| funcion that is only accessible from C \ldots |
| Usually the problem at hand isn't serious enough to warrant rewriting |
| the script in C; perhaps because the problem requires variable-length |
| strings or other data types (like sorted lists of file names) that |
| are easy in the shell but lots of work to implement in C; or perhaps |
| just because you're not sufficiently familiar with C. |
| |
| In such cases, Python may be just the language for you. |
| Python is simple to use, but it is a real programming language, offering |
| much more structure and support for large programs than the shell has. |
| On the other hand, it also offers much more error checking than C, and, |
| being a |
| {\em very-high-level language}, |
| it has high-level data types built in, such as flexible arrays and |
| dictionaries that would cost you days to implement efficiently in C. |
| Because of its more general data types Python is applicable to a |
| much larger problem domain than |
| {\em Awk} |
| or even |
| {\em Perl}, |
| yet most simple things are at least as easy in Python as in those |
| languages. |
| |
| Python allows you to split up your program in modules that can be reused |
| in other Python programs. |
| It comes with a large collection of standard modules that you can use as |
| the basis for your programs --- or as examples to start learning to |
| program in Python. |
| There are also built-in modules that provide things like file I/O, |
| system calls, and even a generic interface to window systems (STDWIN). |
| |
| Python is an interpreted language, which saves you considerable time |
| during program development because no compilation and linking is |
| necessary. |
| The interpreter can be used interactively, which makes it easy to |
| experiment with features of the language, to write throw-away programs, |
| or to test functions during bottom-up program development. |
| It is also a handy desk calculator. |
| |
| Python allows writing very compact and readable programs. |
| Programs written in Python are typically much shorter than equivalent C |
| programs: |
| No declarations are necessary (all type checking is |
| dynamic); statement grouping is done by indentation instead of begin/end |
| brackets; and the high-level data types allow you to express complex |
| operations in a single statement. |
| |
| Python is |
| {\em extensible}: |
| if you know how to program in C it is easy to add a new built-in module |
| to the interpreter, either to perform critical operations at maximum |
| speed, or to link Python programs to libraries that may be only available |
| in binary form (such as a vendor-specific graphics library). |
| Once you are really hooked, you can link the Python interpreter into an |
| application written in C and use it as an extension or command language. |
| |
| \subsection{Where From Here} |
| |
| Now that you are all excited about Python, you'll want to examine it in |
| some more detail. |
| Since the best introduction to a language is using it, you are invited |
| here to do so. |
| |
| In the next section, the mechanics of using the interpreter are |
| explained. |
| This is rather mundane information, but essential for trying out the |
| examples shown later. |
| The rest of the tutorial introduces various features of the Python |
| language and system though examples, beginning with simple expressions, |
| statements and data types, through functions and modules, and finally |
| touching upon advanced concepts like exceptions and classes. |
| |
| \section{Using the Python Interpreter} |
| |
| The Python interpreter is usually installed as |
| {\tt /usr/local/python} |
| on those machines where it is available; putting |
| {\tt /usr/local} |
| in your {\UNIX} shell's search path makes it possible to start it by |
| typing the command |
| \bcode\begin{verbatim} |
| python |
| \end{verbatim}\ecode |
| to the shell. |
| Since the choice of the directory where the interpreter lives is an |
| installation option, other places instead of |
| {\tt /usr/local} |
| are possible; check with your local Python guru or system |
| administrator. |
| |
| The interpreter operates somewhat like the {\UNIX} shell: when called with |
| standard input connected to a tty device, it reads and executes commands |
| interactively; when called with a file name argument or with a file as |
| standard input, it reads and executes a |
| {\em script} |
| from that file.% |
| \footnote{ |
| There is a difference between ``{\tt python file}'' and |
| ``{\tt python $<$file}''. In the latter case {\tt input()} and |
| {\tt raw\_input()} are satisfied from {\em file}, which has |
| already been read until the end by the parser, so they will read |
| EOF immediately. In the former case (which is usually what |
| you want) they are satisfied from whatever file or device is |
| connected to standard input of the Python interpreter. |
| } |
| A third possibility is ``{\tt python -c command [arg] ...}'', which |
| executes the statement(s) in {\tt command}, in analogy of the shell's |
| {\tt -c} option. |
| When available, the script name and additional arguments thereafter are |
| passed to the script in the variable |
| {\tt sys.argv}, |
| which is a list of strings. |
| When {\tt -c command} is used, {\tt sys.argv} is set to {\tt '-c'}. |
| |
| When commands are read from a tty, the interpreter is said to be in |
| {\em interactive\ mode}. |
| In this mode it prompts for the next command with the |
| {\em primary\ prompt}, |
| usually three greater-than signs ({\tt >>>}); for continuation lines |
| it prompts with the |
| {\em secondary\ prompt}, |
| by default three dots ({\tt ...}). |
| Typing an EOF (Control-D) at the primary prompt causes the interpreter |
| to exit with a zero exit status. |
| |
| When an error occurs in interactive mode, the interpreter prints a |
| message and a stack trace and returns to the primary prompt; with input |
| from a file, it exits with a nonzero exit status. |
| (Exceptions handled by an |
| {\tt except} |
| clause in a |
| {\tt try} |
| statement are not errors in this context.) |
| Some errors are unconditionally fatal and cause an exit with a nonzero |
| exit; this applies to internal inconsistencies and some cases of running |
| out of memory. |
| All error messages are written to the standard error stream; normal |
| output from the executed commands is written to standard output. |
| |
| Typing an interrupt (normally Control-C or DEL) to the primary or |
| secondary prompt cancels the input and returns to the primary prompt. |
| Typing an interrupt while a command is being executed raises the |
| {\tt KeyboardInterrupt} |
| exception, which may be handled by a |
| {\tt try} |
| statement. |
| |
| When a module named |
| {\tt foo} |
| is imported, the interpreter searches for a file named |
| {\tt foo.py} |
| in a list of directories specified by the environment variable |
| {\tt PYTHONPATH}. |
| It has the same syntax as the {\UNIX} shell variable |
| {\tt PATH}, |
| i.e., a list of colon-separated directory names. |
| When |
| {\tt PYTHONPATH} |
| is not set, an installation-dependent default path is used, usually |
| {\tt .:/usr/local/lib/python}.% |
| \footnote{ |
| Modules are really searched in the list of directories given by |
| the variable {\tt sys.path} which is initialized from |
| {\tt PYTHONPATH} or from the installation-dependent default. |
| See the section on Standard Modules later. |
| } |
| |
| As an important speed-up of the start-up time of short programs, if a |
| file called {\tt foo.pyc} exists in the directory where {\tt foo.py} |
| is found, this is assumed to contain an already-``compiled'' version |
| of the module {\tt foo}. The last modification time of {\tt foo.py} |
| is recorded in {\tt foo.pyc}, and if these don't match, {\tt foo.pyc} |
| is ignored. Whenever {\tt foo.py} is successfully compiled, an |
| attempt is made to write the compiled version to {\tt foo.pyc}. |
| |
| On BSD'ish {\UNIX} systems, Python scripts can be made directly executable, |
| like shell scripts, by putting the line |
| \bcode\begin{verbatim} |
| #! /usr/local/python |
| \end{verbatim}\ecode |
| (assuming that's the name of the interpreter) at the beginning of the |
| script and giving the file an executable mode. |
| (The |
| {\tt \#!} |
| must be the first two characters of the file.) |
| |
| \subsection{Interactive Input Editing and History Substitution} |
| |
| Some versions of the Python interpreter support editing of the current |
| input line and history substitution, similar to facilities found in the |
| Korn shell and the GNU Bash shell. |
| This is implemented using the |
| {\em GNU\ Readline} |
| library, which supports Emacs-style and vi-style editing. |
| This library has its own documentation which I won't duplicate here; |
| however, the basics are easily explained. |
| |
| If supported,% |
| \footnote{ |
| Perhaps the quickest check to see whether command line editing |
| is supported is typing Control-P to the first Python prompt |
| you get. If it beeps, you have command line editing. |
| If not, you can skip the rest of this section. |
| } |
| input line editing is active whenever the interpreter prints a primary |
| or secondary prompt. |
| The current line can be edited using the conventional Emacs control |
| characters. |
| The most important of these are: |
| C-A (Control-A) moves the cursor to the beginning of the line, C-E to |
| the end, C-B moves it one position to the left, C-F to the right. |
| Backspace erases the character to the left of the cursor, C-D the |
| character to its right. |
| C-K kills (erases) the rest of the line to the right of the cursor, C-Y |
| yanks back the last killed string. |
| C-underscore undoes the last change you made; it can be repeated for |
| cumulative effect. |
| |
| History substitution works as follows. |
| All non-empty input lines issued are saved in a history buffer, |
| and when a new prompt is given you are positioned on a new line at the |
| bottom of this buffer. |
| C-P moves one line up (back) in the history buffer, C-N moves one down. |
| Any line in the history buffer can be edited; an asterisk appears in |
| front of the prompt to mark a line as modified. |
| Pressing the Return key passes the current line to the interpreter. |
| C-R starts an incremental reverse search; C-S starts a forward search. |
| |
| The key bindings and some other parameters of the Readline library can |
| be customized by placing commands in an initialization file called |
| {\tt \$HOME/.initrc}. |
| Key bindings have the form |
| \bcode\begin{verbatim} |
| key-name: function-name |
| \end{verbatim}\ecode |
| and options can be set with |
| \bcode\begin{verbatim} |
| set option-name value |
| \end{verbatim}\ecode |
| Example: |
| \bcode\begin{verbatim} |
| # I prefer vi-style editing: |
| set editing-mode vi |
| # Edit using a single line: |
| set horizontal-scroll-mode On |
| # Rebind some keys: |
| Meta-h: backward-kill-word |
| Control-u: universal-argument |
| \end{verbatim}\ecode |
| Note that the default binding for TAB in Python is to insert a TAB |
| instead of Readline's default filename completion function. |
| If you insist, you can override this by putting |
| \bcode\begin{verbatim} |
| TAB: complete |
| \end{verbatim}\ecode |
| in your |
| {\tt \$HOME/.inputrc}. |
| (Of course, this makes it hard to type indented continuation lines.) |
| |
| This facility is an enormous step forward compared to previous versions of |
| the interpreter; however, some wishes are left: |
| It would be nice if the proper indentation were suggested on |
| continuation lines (the parser knows if an indent token is required |
| next). |
| The completion mechanism might use the interpreter's symbol table. |
| A function to check (or even suggest) matching parentheses, quotes |
| etc. would also be useful. |
| |
| \section{An Informal Introduction to Python} |
| |
| In the following examples, input and output are distinguished by the |
| presence or absence of prompts ({\tt >>>} and {\tt ...}): to repeat the |
| example, you must type everything after the prompt, when the prompt |
| appears; everything on lines that do not begin with a prompt is output |
| from the interpreter. |
| Note that a secondary prompt on a line by itself in an example means you |
| must type a blank line; this is used to end a multi-line command. |
| |
| \subsection{Using Python as a Calculator} |
| |
| Let's try some simple Python commands. |
| Start the interpreter and wait for the primary prompt, |
| {\tt >>>}. |
| The interpreter acts as a simple calculator: you can type an expression |
| at it and it will write the value. |
| Expression syntax is straightforward: the operators |
| {\tt +}, |
| {\tt -}, |
| {\tt *} |
| and |
| {\tt /} |
| work just as in most other languages (e.g., Pascal or C); parentheses |
| can be used for grouping. |
| For example: |
| \bcode\begin{verbatim} |
| >>> # This is a comment |
| >>> 2+2 |
| 4 |
| >>> |
| >>> (50-5+5*6+25)/4 |
| 25 |
| >>> # Division truncates towards zero: |
| >>> 7/3 |
| 2 |
| >>> |
| \end{verbatim}\ecode |
| As in C, the equal sign ({\tt =}) is used to assign a value to a variable. |
| The value of an assignment is not written: |
| \bcode\begin{verbatim} |
| >>> width = 20 |
| >>> height = 5*9 |
| >>> width * height |
| 900 |
| >>> |
| \end{verbatim}\ecode |
| There is some support for floating point, but you can't mix floating |
| point and integral numbers in expression (yet): |
| \bcode\begin{verbatim} |
| >>> 10.0 / 3.3 |
| 3.0303030303 |
| >>> |
| \end{verbatim}\ecode |
| Besides numbers, Python can also manipulate strings, enclosed in single |
| quotes: |
| \bcode\begin{verbatim} |
| >>> 'foo bar' |
| 'foo bar' |
| >>> 'doesn\'t' |
| 'doesn\'t' |
| >>> |
| \end{verbatim}\ecode |
| Strings are written inside quotes and with quotes and other funny |
| characters escaped by backslashes, to show the precise value. |
| (There is also a way to write strings without quotes and escapes.) |
| Strings can be concatenated (glued together) with the |
| {\tt +} |
| operator, and repeated with~{\tt *}: |
| \bcode\begin{verbatim} |
| >>> word = 'Help' + 'A' |
| >>> word |
| 'HelpA' |
| >>> '<' + word*5 + '>' |
| '<HelpAHelpAHelpAHelpAHelpA>' |
| >>> |
| \end{verbatim}\ecode |
| Strings can be subscripted; as in C, the first character of a string has |
| subscript 0. |
| There is no separate character type; a character is simply a string of |
| size one. |
| As in Icon, substrings can be specified with the |
| {\em slice} |
| notation: two subscripts (indices) separated by a colon. |
| \bcode\begin{verbatim} |
| >>> word[4] |
| 'A' |
| >>> word[0:2] |
| 'He' |
| >>> word[2:4] |
| 'lp' |
| >>> # Slice indices have useful defaults: |
| >>> word[:2] # Take first two characters |
| 'He' |
| >>> word[2:] # Drop first two characters |
| 'lpA' |
| >>> # A useful invariant: s[:i] + s[i:] = s |
| >>> word[:3] + word[3:] |
| 'HelpA' |
| >>> |
| \end{verbatim}\ecode |
| Degenerate cases are handled gracefully: an index that is too large is |
| replaced by the string size, an upper bound smaller than the lower bound |
| returns an empty string. |
| \bcode\begin{verbatim} |
| >>> word[1:100] |
| 'elpA' |
| >>> word[10:] |
| '' |
| >>> word[2:1] |
| '' |
| >>> |
| \end{verbatim}\ecode |
| Slice indices (but not simple subscripts) may be negative numbers, to |
| start counting from the right. |
| For example: |
| \bcode\begin{verbatim} |
| >>> word[-2:] # Take last two characters |
| 'pA' |
| >>> word[:-2] # Drop last two characters |
| 'Hel' |
| >>> # But -0 does not count from the right! |
| >>> word[-0:] # (since -0 equals 0) |
| 'HelpA' |
| >>> |
| \end{verbatim}\ecode |
| The best way to remember how slices work is to think of the indices as |
| pointing |
| {\em between} |
| characters, with the left edge of the first character numbered 0. |
| Then the right edge of the last character of a string of |
| {\tt n} |
| characters has index |
| {\tt n}, |
| for example: |
| \bcode\begin{verbatim} |
| +---+---+---+---+---+ |
| | H | e | l | p | A | |
| +---+---+---+---+---+ |
| 0 1 2 3 4 5 |
| -5 -4 -3 -2 -1 |
| \end{verbatim}\ecode |
| The first row of numbers gives the position of the indices 0...5 in the |
| string; the second row gives the corresponding negative indices. |
| For nonnegative indices, the length of a slice is the difference of the |
| indices, if both are within bounds, |
| e.g., |
| the length of |
| {\tt word[1:3]} |
| is 3--1 = 2. |
| |
| Finally, the built-in function {\tt len()} computes the length of a |
| string: |
| \bcode\begin{verbatim} |
| >>> s = 'supercalifragilisticexpialidocious' |
| >>> len(s) |
| 34 |
| >>> |
| \end{verbatim}\ecode |
| Python knows a number of |
| {\em compound} |
| data types, used to group together other values. |
| The most versatile is the |
| {\em list}, |
| which can be written as a list of comma-separated values between square |
| brackets: |
| \bcode\begin{verbatim} |
| >>> a = ['foo', 'bar', 100, 1234] |
| >>> a |
| ['foo', 'bar', 100, 1234] |
| >>> |
| \end{verbatim}\ecode |
| As for strings, list subscripts start at 0: |
| \bcode\begin{verbatim} |
| >>> a[0] |
| 'foo' |
| >>> a[3] |
| 1234 |
| >>> |
| \end{verbatim}\ecode |
| Lists can be sliced, concatenated and so on, like strings: |
| \bcode\begin{verbatim} |
| >>> a[1:3] |
| ['bar', 100] |
| >>> a[:2] + ['bletch', 2*2] |
| ['foo', 'bar', 'bletch', 4] |
| >>> 3*a[:3] + ['Boe!'] |
| ['foo', 'bar', 100, 'foo', 'bar', 100, 'foo', 'bar', 100, 'Boe!'] |
| >>> |
| \end{verbatim}\ecode |
| Unlike strings, which are |
| {\em immutable}, |
| it is possible to change individual elements of a list: |
| \bcode\begin{verbatim} |
| >>> a |
| ['foo', 'bar', 100, 1234] |
| >>> a[2] = a[2] + 23 |
| >>> a |
| ['foo', 'bar', 123, 1234] |
| >>> |
| \end{verbatim}\ecode |
| Assignment to slices is also possible, and this may even change the size |
| of the list: |
| \bcode\begin{verbatim} |
| >>> # Replace some items: |
| >>> a[0:2] = [1, 12] |
| >>> a |
| [1, 12, 123, 1234] |
| >>> # Remove some: |
| >>> a[0:2] = [] |
| >>> a |
| [123, 1234] |
| >>> # Insert some: |
| >>> a[1:1] = ['bletch', 'xyzzy'] |
| >>> a |
| [123, 'bletch', 'xyzzy', 1234] |
| >>> |
| \end{verbatim}\ecode |
| The built-in function {\tt len()} also applies to lists: |
| \bcode\begin{verbatim} |
| >>> len(a) |
| 4 |
| >>> |
| \end{verbatim}\ecode |
| |
| \subsection{Tuples and Sequences} |
| |
| XXX To Be Done. |
| |
| \subsection{First Steps Towards Programming} |
| |
| Of course, we can use Python for more complicated tasks than adding two |
| and two together. |
| For instance, we can write an initial subsequence of the |
| {\em Fibonacci} |
| series as follows: |
| \bcode\begin{verbatim} |
| >>> # Fibonacci series: |
| >>> # the sum of two elements defines the next |
| >>> a, b = 0, 1 |
| >>> while b < 100: |
| ... print b |
| ... a, b = b, a+b |
| ... |
| 1 |
| 1 |
| 2 |
| 3 |
| 5 |
| 8 |
| 13 |
| 21 |
| 34 |
| 55 |
| 89 |
| >>> |
| \end{verbatim}\ecode |
| This example introduces several new features. |
| \begin{itemize} |
| \item |
| The first line contains a |
| {\em multiple\ assignment}: |
| the variables |
| {\tt a} |
| and |
| {\tt b} |
| simultaneously get the new values 0 and 1. |
| On the last line this is used again, demonstrating that the expressions |
| on the right-hand side are all evaluated first before any of the |
| assignments take place. |
| \item |
| The |
| {\tt while} |
| loop executes as long as the condition (here: $b < 100$) remains true. |
| In Python, as in C, any non-zero integer value is true; zero is false. |
| The condition may also be a string or list value, in fact any sequence; |
| anything with a non-zero length is true, empty sequences are false. |
| The test used in the example is a simple comparison. |
| The standard comparison operators are written as |
| {\tt <}, |
| {\tt >}, |
| {\tt =}, |
| {\tt <=}, |
| {\tt >=} |
| and |
| {\tt <>}.% |
| \footnote{ |
| The ambiguity of using {\tt =} |
| for both assignment and equality is resolved by disallowing |
| unparenthesized conditions at the right hand side of assignments. |
| } |
| \item |
| The |
| {\em body} |
| of the loop is |
| {\em indented}: indentation is Python's way of grouping statements. |
| Python does not (yet!) provide an intelligent input line editing |
| facility, so you have to type a tab or space(s) for each indented line. |
| In practice you will prepare more complicated input for Python with a |
| text editor; most text editors have an auto-indent facility. |
| When a compound statement is entered interactively, it must be |
| followed by a blank line to indicate completion (since the parser |
| cannot guess when you have typed the last line). |
| \item |
| The |
| {\tt print} |
| statement writes the value of the expression(s) it is given. |
| It differs from just writing the expression you want to write (as we did |
| earlier in the calculator examples) in the way it handles multiple |
| expressions and strings. |
| Strings are written without quotes and a space is inserted between |
| items, so you can format things nicely, like this: |
| \bcode\begin{verbatim} |
| >>> i = 256*256 |
| >>> print 'The value of i is', i |
| The value of i is 65536 |
| >>> |
| \end{verbatim}\ecode |
| A trailing comma avoids the newline after the output: |
| \bcode\begin{verbatim} |
| >>> a, b = 0, 1 |
| >>> while b < 1000: |
| ... print b, |
| ... a, b = b, a+b |
| ... |
| 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 |
| >>> |
| \end{verbatim}\ecode |
| Note that the interpreter inserts a newline before it prints the next |
| prompt if the last line was not completed. |
| \end{itemize} |
| |
| \subsection{More Control Flow Tools} |
| |
| Besides the {\tt while} statement just introduced, Python knows the |
| usual control flow statements known from other languages, with some |
| twists. |
| |
| \subsubsection{If Statements} |
| |
| Perhaps the most well-known statement type is the {\tt if} statement. |
| For example: |
| \bcode\begin{verbatim} |
| >>> if x < 0: |
| ... x = 0 |
| ... print 'Negative changed to zero' |
| ... elif x = 0: |
| ... print 'Zero' |
| ... elif x = 1: |
| ... print 'Single' |
| ... else: |
| ... print 'More' |
| ... |
| \end{verbatim}\ecode |
| There can be zero or more {\tt elif} parts, and the {\tt else} part is |
| optional. |
| The keyword `{\tt elif}' is short for `{\tt else if}', and is useful to |
| avoid excessive indentation. |
| An {\tt if...elif...elif...} sequence is a substitute for the |
| {\em switch} or {\em case} statements found in other languages. |
| |
| \subsubsection{For Statements} |
| |
| The {\tt for} statement in Python differs a bit from what you may be |
| used to in C or Pascal. |
| Rather than always iterating over an arithmetic progression of numbers |
| (as Pascal), or leaving the user completely free in the iteration test |
| and step (as C), Python's {\tt for} statement iterates over the items |
| of any sequence (e.g., a list or a string). |
| For example (no pun intended): |
| \bcode\begin{verbatim} |
| >>> # Measure some strings: |
| >>> a = ['cat', 'window', 'defenestrate'] |
| >>> for x in a: |
| ... print x, len(x) |
| ... |
| cat 3 |
| window 6 |
| defenestrate 12 |
| >>> |
| \end{verbatim}\ecode |
| |
| \subsubsection{The {\tt range()} Function} |
| |
| If you do need to iterate over a sequence of numbers, the built-in |
| function {\tt range()} comes in handy. |
| It generates lists containing arithmetic progressions, |
| e.g.: |
| \bcode\begin{verbatim} |
| >>> range(10) |
| [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] |
| >>> |
| \end{verbatim}\ecode |
| The given end point is never part of the generated list; |
| {\tt range(10)} generates a list of 10 values, |
| exactly the legal indices for items of a sequence of length 10. |
| It is possible to let the range start at another number, or to specify a |
| different increment (even negative): |
| \bcode\begin{verbatim} |
| >>> range(5, 10) |
| [5, 6, 7, 8, 9] |
| >>> range(0, 10, 3) |
| [0, 3, 6, 9] |
| >>> range(-10, -100, -30) |
| [-10, -40, -70] |
| >>> |
| \end{verbatim}\ecode |
| To iterate over the indices of a sequence, combine {\tt range()} |
| and {\tt len()} as follows: |
| \bcode\begin{verbatim} |
| >>> a = ['Mary', 'had', 'a', 'little', 'boy'] |
| >>> for i in range(len(a)): |
| ... print i, a[i] |
| ... |
| 0 Mary |
| 1 had |
| 2 a |
| 3 little |
| 4 boy |
| >>> |
| \end{verbatim}\ecode |
| |
| \subsubsection{Break Statements and Else Clauses on Loops} |
| |
| The {\tt break} statement breaks out of the smallest enclosing {\tt for} |
| or {\tt while} loop. |
| Loop statements may have an {\tt else} clause; it is executed when the |
| loop terminates through exhaustion of the list (with {\tt for}) or when |
| the condition becomes false (with {\tt while}) but not when the loop is |
| terminated by a {\tt break} statement. |
| This is exemplified by the following loop, which searches for a list |
| item of value 0: |
| \bcode\begin{verbatim} |
| >>> for n in range(2, 10): |
| ... for x in range(2, n): |
| ... if n % x = 0: |
| ... print n, 'equals', x, '*', n/x |
| ... break |
| ... else: |
| ... print n, 'is a prime number' |
| ... |
| 2 is a prime number |
| 3 is a prime number |
| 4 equals 2 * 2 |
| 5 is a prime number |
| 6 equals 2 * 3 |
| 7 is a prime number |
| 8 equals 2 * 4 |
| 9 equals 3 * 3 |
| >>> |
| \end{verbatim}\ecode |
| |
| \subsubsection{Pass Statements} |
| |
| The {\tt pass} statement does nothing. |
| It can be used when a statement is required syntactically but the |
| program requires no action. |
| For example: |
| \bcode\begin{verbatim} |
| >>> while 1: |
| ... pass # Busy-wait for keyboard interrupt |
| ... |
| \end{verbatim}\ecode |
| |
| \subsubsection{Conditions Revisited} |
| |
| XXX To Be Done. |
| |
| \subsection{Defining Functions} |
| |
| We can create a function that writes the Fibonacci series to an |
| arbitrary boundary: |
| \bcode\begin{verbatim} |
| >>> def fib(n): # write Fibonacci series up to n |
| ... a, b = 0, 1 |
| ... while b <= n: |
| ... print b, |
| ... a, b = b, a+b |
| ... |
| >>> # Now call the function we just defined: |
| >>> fib(2000) |
| 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 |
| >>> |
| \end{verbatim}\ecode |
| The keyword |
| {\tt def} |
| introduces a function |
| {\em definition}. |
| It must be followed by the function name and the parenthesized list of |
| formal parameters. |
| The statements that form the body of the function starts at the next |
| line, indented by a tab stop. |
| The |
| {\em execution} |
| of a function introduces a new symbol table used for the local variables |
| of the function. |
| More precisely, all variable assignments in a function store the value |
| in the local symbol table; variable references first look in the local |
| symbol table, then in the global symbol table, and then in the table of |
| built-in names. |
| Thus, the global symbol table is |
| {\em read-only} |
| within a function. |
| The actual parameters (arguments) to a function call are introduced in |
| the local symbol table of the called function when it is called; |
| thus, arguments are passed using |
| {\em call\ by\ value}.% |
| \footnote{ |
| Actually, {\em call by object reference} would be a better |
| description, since if a mutable object is passed, the caller |
| will see any changes the callee makes to it (e.g., items |
| inserted into a list). |
| } |
| When a function calls another function, a new local symbol table is |
| created for that call. |
| |
| A function definition introduces the function name in the global symbol |
| table. |
| The value has a type that is recognized by the interpreter as a |
| user-defined function. |
| This value can be assigned to another name which can then also be used |
| as a function. |
| This serves as a general renaming mechanism: |
| \bcode\begin{verbatim} |
| >>> fib |
| <function object at 10042ed0> |
| >>> f = fib |
| >>> f(100) |
| 1 1 2 3 5 8 13 21 34 55 89 |
| >>> |
| \end{verbatim}\ecode |
| You might object that |
| {\tt fib} |
| is not a function but a procedure. |
| In Python, as in C, procedures are just functions that don't return a |
| value. |
| In fact, technically speaking, procedures do return a value, albeit a |
| rather boring one. |
| This value is called {\tt None} (it's a built-in name). |
| Writing the value {\tt None} is normally suppressed by the interpreter |
| if it would be the only value written. |
| You can see it if you really want to: |
| \bcode\begin{verbatim} |
| >>> print fib(0) |
| None |
| >>> |
| \end{verbatim}\ecode |
| It is simple to write a function that returns a list of the numbers of |
| the Fibonacci series, instead of printing it: |
| \bcode\begin{verbatim} |
| >>> def fib2(n): # return Fibonacci series up to n |
| ... result = [] |
| ... a, b = 0, 1 |
| ... while b <= n: |
| ... result.append(b) # see below |
| ... a, b = b, a+b |
| ... return result |
| ... |
| >>> f100 = fib2(100) # call it |
| >>> f100 # write the result |
| [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] |
| >>> |
| \end{verbatim}\ecode |
| This example, as usual, demonstrates some new Python features: |
| \begin{itemize} |
| \item |
| The |
| {\tt return} |
| statement returns with a value from a function. |
| {\tt return} |
| without an expression argument is used to return from the middle of a |
| procedure (falling off the end also returns from a proceduce). |
| \item |
| The statement |
| {\tt ret.append(b)} |
| calls a |
| {\em method} |
| of the list object |
| {\tt ret}. |
| A method is a function that `belongs' to an object and is named |
| {\tt obj.methodname}, |
| where |
| {\tt obj} |
| is some object (this may be an expression), and |
| {\tt methodname} |
| is the name of a method that is defined by the object's type. |
| Different types define different methods. |
| Methods of different types may have the same name without causing |
| ambiguity. |
| See the section on classes, later, to find out how you can define your |
| own object types and methods. |
| The method |
| {\tt append} |
| shown in the example, is defined for list objects; it adds a new element |
| at the end of the list. |
| In this case it is equivalent to |
| {\tt ret = ret + [b]}, |
| but more efficient.% |
| \footnote{ |
| There is a subtle semantic difference if the object |
| is referenced from more than one place. |
| } |
| \end{itemize} |
| The list object type has two more methods: |
| \begin{description} |
| \item[{\tt insert(i, x)}] |
| Inserts an item at a given position. |
| The first argument is the index of the element before which to insert, |
| so {\tt a.insert(0, x)} inserts at the front of the list, and |
| {\tt a.insert(len(a), x)} is equivalent to {\tt a.append(x)}. |
| \item[{\tt sort()}] |
| Sorts the elements of the list. |
| \end{description} |
| For example: |
| \bcode\begin{verbatim} |
| >>> a = [10, 100, 1, 1000] |
| >>> a.insert(2, -1) |
| >>> a |
| [10, 100, -1, 1, 1000] |
| >>> a.sort() |
| >>> a |
| [-1, 1, 10, 100, 1000] |
| >>> # Strings are sorted according to ASCII: |
| >>> b = ['Mary', 'had', 'a', 'little', 'boy'] |
| >>> b.sort() |
| >>> b |
| ['Mary', 'a', 'boy', 'had', 'little'] |
| >>> |
| \end{verbatim}\ecode |
| |
| \subsection{Modules} |
| |
| If you quit from the Python interpreter and enter it again, the |
| definitions you have made (functions and variables) are lost. |
| Therefore, if you want to write a somewhat longer program, you are |
| better off using a text editor to prepare the input for the interpreter |
| and run it with that file as input instead. |
| This is known as creating a |
| {\em script}. |
| As your program gets longer, you may want to split it into several files |
| for easier maintenance. |
| You may also want to use a handy function that you've written in several |
| programs without copying its definition into each program. |
| To support this, Python has a way to put definitions in a file and use |
| them in a script or in an interactive instance of the interpreter. |
| Such a file is called a |
| {\em module}; |
| definitions from a module can be |
| {\em imported} |
| into other modules or into the |
| {\em main} |
| module (the collection of variables that you have access to in |
| a script and in calculator mode). |
| |
| A module is a file containing Python definitions and statements. |
| The file name is the module name with the suffix |
| {\tt .py} |
| appended. |
| For instance, use your favorite text editor to create a file called |
| {\tt fibo.py} |
| in the current directory with the following contents: |
| \bcode\begin{verbatim} |
| # Fibonacci numbers module |
| |
| def fib(n): # write Fibonacci series up to n |
| a, b = 0, 1 |
| while b <= n: |
| print b, |
| a, b = b, a+b |
| |
| def fib2(n): # return Fibonacci series up to n |
| ret = [] |
| a, b = 0, 1 |
| while b <= n: |
| ret.append(b) |
| a, b = b, a+b |
| return ret |
| \end{verbatim}\ecode |
| Now enter the Python interpreter and import this module with the |
| following command: |
| \bcode\begin{verbatim} |
| >>> import fibo |
| >>> |
| \end{verbatim}\ecode |
| This does not enter the names of the functions defined in |
| {\tt fibo} |
| directly in the symbol table; it only enters the module name |
| {\tt fibo} |
| there. |
| Using the module name you can access the functions: |
| \bcode\begin{verbatim} |
| >>> fibo.fib(1000) |
| 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 |
| >>> fibo.fib2(100) |
| [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] |
| >>> |
| \end{verbatim}\ecode |
| If you intend to use a function often you can assign it to a local name: |
| \bcode\begin{verbatim} |
| >>> fib = fibo.fib |
| >>> fib(500) |
| 1 1 2 3 5 8 13 21 34 55 89 144 233 377 |
| >>> |
| \end{verbatim}\ecode |
| |
| \subsubsection{More on Modules} |
| |
| A module can contain executable statements as well as function |
| definitions. |
| These statements are intended to initialize the module. |
| They are executed only the |
| {\em first} |
| time the module is imported somewhere.% |
| \footnote{ |
| In fact function definitions are also `statements' that are |
| `executed'; the execution enters the function name in the |
| module's global symbol table. |
| } |
| |
| Each module has its own private symbol table, which is used as the |
| global symbol table by all functions defined in the module. |
| Thus, the author of a module can use global variables in the module |
| without worrying about accidental clashes with a user's global |
| variables. |
| On the other hand, if you know what you are doing you can touch a |
| module's global variables with the same notation used to refer to its |
| functions, |
| {\tt modname.itemname}. |
| |
| Modules can import other modules. |
| It is customary but not required to place all |
| {\tt import} |
| statements at the beginning of a module (or script, for that matter). |
| The imported module names are placed in the importing module's global |
| symbol table. |
| |
| There is a variant of the |
| {\tt import} |
| statement that imports names from a module directly into the importing |
| module's symbol table. |
| For example: |
| \bcode\begin{verbatim} |
| >>> from fibo import fib, fib2 |
| >>> fib(500) |
| 1 1 2 3 5 8 13 21 34 55 89 144 233 377 |
| >>> |
| \end{verbatim}\ecode |
| This does not introduce the module name from which the imports are taken |
| in the local symbol table (so in the example, {\tt fibo} is not |
| defined). |
| |
| There is even a variant to import all names that a module defines: |
| \bcode\begin{verbatim} |
| >>> from fibo import * |
| >>> fib(500) |
| 1 1 2 3 5 8 13 21 34 55 89 144 233 377 |
| >>> |
| \end{verbatim}\ecode |
| This imports all names except those beginning with an underscore |
| ({\tt \_}). |
| |
| \subsubsection{Standard Modules} |
| |
| Python comes with a library of standard modules, described in a separate |
| document (Python Library and Module Reference). |
| Some modules are built into the interpreter; these provide access to |
| operations that are not part of the core of the language but are |
| nevertheless built in, either for efficiency or to provide access to |
| operating system primitives such as system calls. |
| The set of such modules is a configuration option; e.g., the |
| {\tt amoeba} |
| module is only provided on systems that somehow support Amoeba |
| primitives. |
| One particular module deserves some attention: |
| {\tt sys}, |
| which is built into every Python interpreter. |
| The variables |
| {\tt sys.ps1} |
| and |
| {\tt sys.ps2} |
| define the strings used as primary and secondary prompts: |
| \bcode\begin{verbatim} |
| >>> import sys |
| >>> sys.ps1 |
| '>>> ' |
| >>> sys.ps2 |
| '... ' |
| >>> sys.ps1 = 'C> ' |
| C> print 'Yuck!' |
| Yuck! |
| C> |
| \end{verbatim}\ecode |
| These two variables are only defined if the interpreter is in |
| interactive mode. |
| |
| The variable |
| {\tt sys.path} |
| is a list of strings that determine the interpreter's search path for |
| modules. |
| It is initialized to a default path taken from the environment variable |
| {\tt PYTHONPATH}, |
| or from a built-in default if |
| {\tt PYTHONPATH} |
| is not set. |
| You can modify it using standard list operations, e.g.: |
| \bcode\begin{verbatim} |
| >>> import sys |
| >>> sys.path.append('/ufs/guido/lib/python') |
| >>> |
| \end{verbatim}\ecode |
| |
| \subsection{Errors and Exceptions} |
| |
| Until now error messages haven't yet been mentioned, but if you have |
| tried out the examples you have probably seen some. |
| There are (at least) two distinguishable kinds of errors: |
| {\em syntax\ errors} |
| and |
| {\em exceptions}. |
| |
| \subsubsection{Syntax Errors} |
| |
| Syntax errors, also known as parsing errors, are perhaps the most common |
| kind of complaint you get while you are still learning Python: |
| \bcode\begin{verbatim} |
| >>> while 1 print 'Hello world' |
| Parsing error: file <stdin>, line 1: |
| while 1 print 'Hello world' |
| ^ |
| Unhandled exception: run-time error: syntax error |
| >>> |
| \end{verbatim}\ecode |
| The parser repeats the offending line and displays a little `arrow' |
| pointing at the earliest point in the line where the error was detected. |
| The error is caused by (or at least detected at) the token |
| {\em preceding} |
| the arrow: in the example, the error is detected at the keyword |
| {\tt print}, since a colon ({\tt :}) is missing before it. |
| File name and line number are printed so you know where to look in case |
| the input came from a script. |
| |
| \subsubsection{Exceptions} |
| |
| Even if a statement or expression is syntactically correct, it may cause |
| an error when an attempt is made to execute it: |
| \bcode\small\begin{verbatim} |
| >>> 10 * (1/0) |
| Unhandled exception: run-time error: integer division by zero |
| Stack backtrace (innermost last): |
| File "<stdin>", line 1 |
| >>> 4 + foo*3 |
| Unhandled exception: undefined name: foo |
| Stack backtrace (innermost last): |
| File "<stdin>", line 1 |
| >>> '2' + 2 |
| Unhandled exception: type error: illegal argument type for built-in operation |
| Stack backtrace (innermost last): |
| File "<stdin>", line 1 |
| >>> |
| \end{verbatim}\ecode |
| Errors detected during execution are called |
| {\em exceptions} |
| and are not unconditionally fatal: you will soon learn how to handle |
| them in Python programs. |
| Most exceptions are not handled by programs, however, and result |
| in error messages as shown here. |
| |
| The first line of the error message indicates what happened. |
| Exceptions come in different types, and the type is printed as part of |
| the message: the types in the example are |
| {\tt run-time error}, |
| {\tt undefined name} |
| and |
| {\tt type error}. |
| The rest of the line is a detail whose interpretation depends on the |
| exception type. |
| |
| The rest of the error message shows the context where the |
| exception happened. |
| In general it contains a stack backtrace listing source lines; however, |
| it will not display lines read from standard input. |
| |
| Here is a summary of the most common exceptions: |
| \begin{itemize} |
| \item |
| {\em Run-time\ errors} |
| are generally caused by wrong data used by the program; this can be the |
| programmer's fault or caused by bad input. |
| The detail states the cause of the error in more detail. |
| \item |
| {\em Undefined\ name} |
| errors are more serious: these are usually caused by misspelled |
| identifiers.% |
| \footnote{ |
| The parser does not check whether names used in a program are at |
| all defined elsewhere in the program, so such checks are |
| postponed until run-time. The same holds for type checking. |
| } |
| The detail is the offending identifier. |
| \item |
| {\em Type\ errors} |
| are also pretty serious: this is another case of using wrong data (or |
| better, using data the wrong way), but here the error can be glanced |
| from the object type(s) alone. |
| The detail shows in what context the error was detected. |
| \end{itemize} |
| |
| \subsubsection{Handling Exceptions} |
| |
| It is possible to write programs that handle selected exceptions. |
| Look at the following example, which prints a table of inverses of |
| some floating point numbers: |
| \bcode\begin{verbatim} |
| >>> numbers = [0.3333, 2.5, 0.0, 10.0] |
| >>> for x in numbers: |
| ... print x, |
| ... try: |
| ... print 1.0 / x |
| ... except RuntimeError: |
| ... print '*** has no inverse ***' |
| ... |
| 0.3333 3.00030003 |
| 2.5 0.4 |
| 0 *** has no inverse *** |
| 10 0.1 |
| >>> |
| \end{verbatim}\ecode |
| The {\tt try} statement works as follows. |
| \begin{itemize} |
| \item |
| First, the |
| {\em try\ clause} |
| (the statement(s) between the {\tt try} and {\tt except} keywords) is |
| executed. |
| \item |
| If no exception occurs, the |
| {\em except\ clause} |
| is skipped and execution of the {\tt try} statement is finished. |
| \item |
| If an exception occurs during execution of the try clause, and its |
| type matches the exception named after the {\tt except} keyword, the |
| rest of the try clause is skipped, the except clause is executed, and |
| then execution continues after the {\tt try} statement. |
| \item |
| If an exception occurs which does not match the exception named in the |
| except clause, it is passed on to outer try statements; if no handler is |
| found, it is an |
| {\em unhandled\ exception} |
| and execution stops with a message as shown above. |
| \end{itemize} |
| A {\tt try} statement may have more than one except clause, to specify |
| handlers for different exceptions. |
| At most one handler will be executed. |
| Handlers only handle exceptions that occur in the corresponding try |
| clause, not in other handlers of the same {\tt try} statement. |
| An except clause may name multiple exceptions as a parenthesized list, |
| e.g.: |
| \bcode\begin{verbatim} |
| ... except (RuntimeError, TypeError, NameError): |
| ... pass |
| \end{verbatim}\ecode |
| The last except clause may omit the exception name(s), to serve as a |
| wildcard. |
| Use this with extreme caution! |
| |
| When an exception occurs, it may have an associated value, also known as |
| the exceptions's |
| {\em argument}. |
| The presence and type of the argument depend on the exception type. |
| For exception types which have an argument, the except clause may |
| specify a variable after the exception name (or list) to receive the |
| argument's value, as follows: |
| \bcode\begin{verbatim} |
| >>> try: |
| ... foo() |
| ... except NameError, x: |
| ... print 'name', x, 'undefined' |
| ... |
| name foo undefined |
| >>> |
| \end{verbatim}\ecode |
| If an exception has an argument, it is printed as the third part |
| (`detail') of the message for unhandled exceptions. |
| |
| Standard exception names are built-in identifiers (not reserved |
| keywords). |
| These are in fact string objects whose |
| {\em object\ identity} |
| (not their value!) identifies the exceptions.% |
| \footnote{ |
| There should really be a separate exception type; it is pure |
| laziness that exceptions are identified by strings, and this may |
| be fixed in the future. |
| } |
| The string is printed as the second part of the message for unhandled |
| exceptions. |
| Their names and values are: |
| \bcode\begin{verbatim} |
| EOFError 'end-of-file read' |
| KeyboardInterrupt 'keyboard interrupt' |
| MemoryError 'out of memory' * |
| NameError 'undefined name' * |
| RuntimeError 'run-time error' * |
| SystemError 'system error' * |
| TypeError 'type error' * |
| \end{verbatim}\ecode |
| The meanings should be clear enough. |
| Those exceptions with a {\tt *} in the third column have an argument. |
| |
| Exception handlers don't just handle exceptions if they occur |
| immediately in the try clause, but also if they occur inside functions |
| that are called (even indirectly) in the try clause. |
| For example: |
| \bcode\begin{verbatim} |
| >>> def this_fails(): |
| ... x = 1/0 |
| ... |
| >>> try: |
| ... this_fails() |
| ... except RuntimeError, detail: |
| ... print 'Handling run-time error:', detail |
| ... |
| Handling run-time error: integer division by zero |
| >>> |
| \end{verbatim}\ecode |
| |
| \subsubsection{Raising Exceptions} |
| |
| The {\tt raise} statement allows the programmer to force a specified |
| exception to occur. |
| For example: |
| \bcode\begin{verbatim} |
| >>> raise NameError, 'Hi There!' |
| Unhandled exception: undefined name: Hi There! |
| Stack backtrace (innermost last): |
| File "<stdin>", line 1 |
| >>> |
| \end{verbatim}\ecode |
| The first argument to {\tt raise} names the exception to be raised. |
| The optional second argument specifies the exception's argument. |
| |
| \subsubsection{User-defined Exceptions} |
| |
| Programs may name their own exceptions by assigning a string to a |
| variable. |
| For example: |
| \bcode\begin{verbatim} |
| >>> my_exc = 'nobody likes me!' |
| >>> try: |
| ... raise my_exc, 2*2 |
| ... except my_exc, val: |
| ... print 'My exception occurred, value:', val |
| ... |
| My exception occured, value: 4 |
| >>> raise my_exc, 1 |
| Unhandled exception: nobody likes me!: 1 |
| Stack backtrace (innermost last): |
| File "<stdin>", line 7 |
| >>> |
| \end{verbatim}\ecode |
| Many standard modules use this to report errors that may occur in |
| functions they define. |
| |
| \subsubsection{Defining Clean-up Actions} |
| |
| The {\tt try} statement has another optional clause which is intended to |
| define clean-up actions that must be executed under all circumstances. |
| For example: |
| \bcode\begin{verbatim} |
| >>> try: |
| ... raise KeyboardInterrupt |
| ... finally: |
| ... print 'Goodbye, world!' |
| ... |
| Goodbye, world! |
| Unhandled exception: keyboard interrupt |
| Stack backtrace (innermost last): |
| File "<stdin>", line 2 |
| >>> |
| \end{verbatim}\ecode |
| The |
| {\em finally\ clause} |
| must follow the except clauses(s), if any. |
| It is executed whether or not an exception occurred. |
| If the exception is handled, the finally clause is executed after the |
| handler (and even if another exception occurred in the handler). |
| It is also executed when the {\tt try} statement is left via a |
| {\tt break} or {\tt return} statement. |
| |
| \subsection{Classes} |
| |
| Classes in Python make it possible to play the game of encapsulation in a |
| somewhat different way than it is played with modules. |
| Classes are an advanced topic and are probably best skipped on the first |
| encounter with Python. |
| |
| \subsubsection{Prologue} |
| |
| Python's class mechanism is not particularly elegant, but quite powerful. |
| It is a mixture of the class mechanisms found in C++ and Modula-3. |
| As is true for modules, classes in Python do not put an absolute barrier |
| between definition and user, but rather rely on the politeness of the |
| user not to ``break into the definition.'' |
| The most important features of classes are retained with full power, |
| however: the class inheritance mechanism allows multiple base classes, |
| a derived class can override any method of its base class(es), a method |
| can call the method of a base class with the same name. |
| Objects can contain an arbitrary amount of private data. |
| |
| In C++ terminology, all class members (including data members) are |
| {\em public}, |
| and all member functions (methods) are |
| {\em virtual}. |
| There are no special constructors or destructors. |
| As in Modula-3, there are no shorthands for referencing the object's |
| members from its methods: the method function is declared with an |
| explicit first argument representing the object, which is provided |
| implicitly by the call. |
| As in Smalltalk, classes themselves are objects, albeit in the wider |
| sense of the word: in Python, all data types are objects. |
| This provides semantics for renaming or aliasing. |
| But, just like in C++ or Modula-3, the built-in types cannot be used as |
| base classes for extension by the user. |
| Also, like Modula-3 but unlike C++, the built-in operators with special |
| syntax (arithmetic operators, subscripting etc.) cannot be redefined for |
| class members.% |
| \footnote{ |
| They can be redefined for new object types implemented in C in |
| extensions to the interpreter, however. It would require only a |
| naming convention and a relatively small change to the |
| interpreter to allow operator overloading for classes, so |
| perhaps someday... |
| } |
| |
| \subsubsection{A Simple Example} |
| |
| Consider the following example, which defines a class {\tt Set} |
| representing a (finite) mathematical set with operations to add and |
| remove elements, a membership test, and a request for the size of the |
| set. |
| \bcode\begin{verbatim} |
| class Set(): |
| def new(self): |
| self.elements = [] |
| return self |
| def add(self, e): |
| if e not in self.elements: |
| self.elements.append(e) |
| def remove(self, e): |
| if e in self.elements: |
| for i in range(len(self.elements)): |
| if self.elements[i] = e: |
| del self.elements[i] |
| break |
| def is_element(self, e): |
| return e in self.elements |
| def size(self): |
| return len(self.elements) |
| \end{verbatim}\ecode |
| Note that the class definition looks like a big compound statement, |
| with all the function definitons indented repective to the |
| {\tt class} |
| keyword. |
| |
| Let's assume that this |
| {\em class\ definition} |
| is the only contents of the module file |
| {\tt SetClass.py}. |
| We can then use it in a Python program as follows: |
| \bcode\begin{verbatim} |
| >>> from SetClass import Set |
| >>> a = Set().new() # create a Set object |
| >>> a.add(2) |
| >>> a.add(3) |
| >>> a.add(1) |
| >>> a.add(1) |
| >>> if a.is_element(3): print '3 is in the set' |
| ... |
| 3 is in the set |
| >>> if not a.is_element(4): print '4 is not in the set' |
| ... |
| 4 is not in the set |
| >>> print 'a has', a.size(), 'elements' |
| a has 3 elements |
| >>> a.remove(1) |
| >>> print 'now a has', a.size(), 'elements' |
| >>> |
| now a has 2 elements |
| >>> |
| \end{verbatim}\ecode |
| From the example we learn in the first place that the functions defined |
| in the class (e.g., |
| {\tt add}) |
| can be called using the |
| {\em member} |
| notation for the object |
| {\tt a}. |
| The member function is called with one less argument than it is defined: |
| the object is implicitly passed as the first argument. |
| Thus, the call |
| {\tt a.add(2)} |
| is equivalent to |
| {\tt Set.add(a, 2)}. |
| |
| XXX This section is not complete yet! Inheritance! |
| |
| \section{XXX P.M.} |
| |
| \begin{itemize} |
| \item The {\tt del} statement. |
| \item The {\tt dir()} function. |
| \item Tuples. |
| \item Dictionaries. |
| \item Objects and types in general. |
| \item Backquotes. |
| \item Output formatting. |
| \item And/Or/Not. |
| \item ``.pyc'' files. |
| \end{itemize} |
| |
| \end{document} |