| % Format this file with latex. |
| |
| \documentstyle[myformat]{report} |
| |
| \title{\bf |
| Python Tutorial |
| } |
| |
| \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 |
| ``throw-away programming'' |
| and 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, the Apple Macintosh O.S., |
| and MS-DOS. |
| |
| 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 {\em Python |
| Library Reference} document. The {\em Python Reference Manual} gives |
| a more formal definition of the language. |
| |
| \end{abstract} |
| |
| \pagebreak |
| |
| \tableofcontents |
| |
| \pagebreak |
| |
| \pagenumbering{arabic} |
| |
| \chapter{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 many 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 of 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, |
| sockets, and even a generic interface to window systems (STDWIN). |
| |
| Python is an interpreted language, which can save 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, for several reasons: |
| \begin{itemize} |
| \item |
| the high-level data types allow you to express complex operations in a |
| single statement; |
| \item |
| statement grouping is done by indentation instead of begin/end |
| brackets; |
| \item |
| no variable or argument declarations are necessary. |
| \end{itemize} |
| |
| Python is {\em extensible}: if you know how to program in C it is easy |
| to add a new built-in |
| function or |
| module to the interpreter, either to |
| perform critical operations at maximum speed, or to link Python |
| programs to libraries that may only be 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 for that application. |
| |
| By the way, the language is named after the BBC show ``Monty |
| Python's Flying Circus'' and has nothing to do with nasty reptiles... |
| |
| \section{Where From Here} |
| |
| Now that you are all excited about Python, you'll want to examine it |
| in some more detail. Since the best way to learn a language is |
| using it, you are invited here to do so. |
| |
| In the next chapter, 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. |
| |
| When you're through with the turtorial (or just getting bored), you |
| should read the Library Reference, which gives complete (though terse) |
| reference material about built-in and standard types, functions and |
| modules that can save you a lot of time when writing Python programs. |
| |
| \chapter{Using the Python Interpreter} |
| |
| \section{Invoking the 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 are possible; check with |
| your local Python guru or system administrator. (E.g., {\tt |
| /usr/local/bin/python} is a popular alternative location.) |
| |
| 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. |
| |
| A third way of starting the interpreter is |
| ``{\tt python -c command [arg] ...}'', which |
| executes the statement(s) in {\tt command}, analogous to the shell's |
| {\tt -c} option. Since Python statements often contain spaces or other |
| characters that are special to the shell, it is best to quote {\tt |
| command} in its entirety with double quotes. |
| |
| Note that there is a difference between ``{\tt python file}'' and |
| ``{\tt python $<$file}''. In the latter case, input requests from the |
| program, such as calls to {\tt input()} and {\tt raw\_input()}, are |
| satisfied from {\em file}. Since this file has already been read |
| until the end by the parser before the program starts executing, the |
| program will encounter 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. |
| |
| \subsection{Argument Passing} |
| |
| When known to the interpreter, the script name and additional |
| arguments thereafter are passed to the script in the variable {\tt |
| sys.argv}, which is a list of strings. Its length is at least one; |
| when no script and no arguments are given, {\tt sys.argv[0]} is an |
| empty string. When the script name is given as {\tt '-'} (meaning |
| standard input), {\tt sys.argv[0]} is set to {\tt '-'}. When {\tt -c |
| command} is used, {\tt sys.argv[0]} is set to {\tt '-c'}. Options |
| found after {\tt -c command} are not consumed by the Python |
| interpreter's option processing but left in {\tt sys.argv} for the |
| command to handle. |
| |
| \subsection{Interactive Mode} |
| |
| 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. |
| |
| The interpreter prints a welcome message stating its version number |
| and a copyright notice before printing the first prompt, e.g.: |
| |
| \bcode\begin{verbatim} |
| python |
| Python 0.9.5 (Jan 2 1992). |
| Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam |
| >>> |
| \end{verbatim}\ecode |
| |
| \section{The Interpreter and its Environment} |
| |
| \subsection{Error Handling} |
| |
| When an error occurs, the interpreter prints an error |
| message and a stack trace. In interactive mode, it then returns to |
| the primary prompt; when input came from a file, it exits with a |
| nonzero exit status after printing |
| the stack trace. (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 the interrupt character (usually Control-C or DEL) to the |
| primary or secondary prompt cancels the input and returns to the |
| primary prompt.% |
| \footnote{ |
| A problem with the GNU Readline package may prevent this. |
| } |
| Typing an interrupt while a command is executing raises the {\tt |
| KeyboardInterrupt} exception, which may be handled by a {\tt try} |
| statement. |
| |
| \subsection{The Module Search Path} |
| |
| When a module named {\tt foo} is imported, the interpreter searches |
| for a file named {\tt foo.py} in the 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}. |
| |
| Actually, modules are searched in the list of directories given by the |
| variable {\tt sys.path} which is initialized from {\tt PYTHONPATH} or |
| the installation-dependent default. This allows Python programs that |
| know what they're doing to modify or replace the module search path. |
| See the section on Standard Modules later. |
| |
| \subsection{``Compiled'' Python files} |
| |
| As an important speed-up of the start-up time for short programs that |
| use a lot of standard modules, 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 |
| modification time of the version of {\tt foo.py} used to create {\tt |
| foo.pyc} is recorded in {\tt foo.pyc}, and the file is ignored if |
| these don't match. |
| |
| Whenever {\tt foo.py} is successfully compiled, an attempt is made to |
| write the compiled version to {\tt foo.pyc}. It is not an error if |
| this attempt fails; if for any reason the file is not written |
| completely, the resulting {\tt foo.pyc} file will be recognized as |
| invalid and thus ignored later. |
| |
| \subsection{Executable Python scripts} |
| |
| 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. |
| |
| \section{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. |
| |
| 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 nothing appears to |
| happen, or if \verb/^P/ is echoed, you can skip the rest of this |
| section. |
| |
| \subsection{Line Editing} |
| |
| If supported, 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. |
| |
| \subsection{History Substitution} |
| |
| 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. |
| |
| \subsection{Key Bindings} |
| |
| The key bindings and some other parameters of the Readline library can |
| be customized by placing commands in an initialization file called |
| {\tt \$HOME/.inputrc}. Key bindings have the form |
| |
| \bcode\begin{verbatim} |
| key-name: function-name |
| \end{verbatim}\ecode |
| % |
| or |
| |
| \bcode\begin{verbatim} |
| "string": function-name |
| \end{verbatim}\ecode |
| % |
| and options can be set with |
| |
| \bcode\begin{verbatim} |
| set option-name value |
| \end{verbatim}\ecode |
| % |
| For 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 |
| "\C-u": universal-argument |
| "\C-x\C-r": re-read-init-file |
| \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...) |
| |
| \subsection{Commentary} |
| |
| 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 |
| command to check (or even suggest) matching parentheses, quotes etc. |
| would also be useful. |
| |
| \chapter{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; lines that do not begin with a prompt are output from |
| the interpreter.% |
| \footnote{ |
| I'd prefer to use different fonts to distinguish input |
| from output, but the amount of LaTeX hacking that would require |
| is currently beyond my ability. |
| } |
| 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. |
| |
| \section{Using Python as a Calculator} |
| |
| Let's try some simple Python commands. Start the interpreter and wait |
| for the primary prompt, {\tt >>>}. (It shouldn't take long.) |
| |
| \subsection{Numbers} |
| |
| 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 like 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*6)/4 |
| 5 |
| >>> # Division truncates towards zero: |
| >>> 7/3 |
| 2 |
| >>> |
| \end{verbatim}\ecode |
| % |
| Like 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 |
| % |
| A value can be assigned to several variables simultaneously: |
| |
| \bcode\begin{verbatim} |
| >>> # Zero x, y and z |
| >>> x = y = z = 0 |
| >>> |
| \end{verbatim}\ecode |
| % |
| There is full support for floating point; operators with mixed type |
| operands convert the integer operand to floating point: |
| |
| \bcode\begin{verbatim} |
| >>> 4 * 2.5 / 3.3 |
| 3.0303030303 |
| >>> 7.0 / 2 |
| 3.5 |
| >>> |
| \end{verbatim}\ecode |
| |
| \subsection{Strings} |
| |
| 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 the same way as they are typed for input: inside |
| quotes and with quotes and other funny characters escaped by |
| backslashes, to show the precise value. (The {\tt print} statement, |
| described later, can be used to write strings without quotes or |
| 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 (indexed); like in C, the first character of |
| a string has subscript (index) 0. |
| |
| There is no separate character type; a character is simply a string of |
| size one. Like in Icon, substrings can be specified with the {\em |
| slice} notation: two indices separated by a colon. |
| |
| \bcode\begin{verbatim} |
| >>> word[4] |
| 'A' |
| >>> word[0:2] |
| 'He' |
| >>> word[2:4] |
| 'lp' |
| >>> |
| \end{verbatim}\ecode |
| % |
| Slice indices have useful defaults; an omitted first index defaults to |
| zero, an omitted second index defaults to the size of the string being |
| sliced. |
| |
| \bcode\begin{verbatim} |
| >>> word[:2] # The first two characters |
| 'He' |
| >>> word[2:] # All but the first two characters |
| 'lpA' |
| >>> |
| \end{verbatim}\ecode |
| % |
| Here's a useful invariant of slice operations: \verb\s[:i] + s[i:]\ |
| equals \verb\s\. |
| |
| \bcode\begin{verbatim} |
| >>> word[:2] + word[2:] |
| 'HelpA' |
| >>> word[:3] + word[3:] |
| 'HelpA' |
| >>> |
| \end{verbatim}\ecode |
| % |
| Degenerate slice indices 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 |
| % |
| Indices may be negative numbers, to start counting from the right. |
| For example: |
| |
| \bcode\begin{verbatim} |
| >>> word[-1] # The last character |
| 'A' |
| >>> word[-2] # The last-but-one character |
| 'p' |
| >>> word[-2:] # The last two characters |
| 'pA' |
| >>> word[:-2] # All but the last two characters |
| 'Hel' |
| >>> |
| \end{verbatim}\ecode |
| % |
| But note that -0 is really the same as 0, so it does not count from |
| the right! |
| |
| \bcode\begin{verbatim} |
| >>> word[-0] # (since -0 equals 0) |
| 'H' |
| >>> |
| \end{verbatim}\ecode |
| % |
| Out-of-range negative slice indices are truncated, but don't try this |
| for single-element (non-slice) indices: |
| |
| \bcode\begin{verbatim} |
| >>> word[-100:] |
| 'HelpA' |
| >>> word[-10] # error |
| Unhandled exception: IndexError: string index out of range |
| >>> |
| \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. |
| The slice from \verb\i\ to \verb\j\ consists of all characters between |
| the edges labeled \verb\i\ and \verb\j\, respectively. |
| |
| For nonnegative indices, the length of a slice is the difference of |
| the indices, if both are within bounds, e.g., the length of |
| \verb\word[1:3]\ is 2. |
| |
| The built-in function {\tt len()} returns the length of a string: |
| |
| \bcode\begin{verbatim} |
| >>> s = 'supercalifragilisticexpialidocious' |
| >>> len(s) |
| 34 |
| >>> |
| \end{verbatim}\ecode |
| |
| \subsection{Lists} |
| |
| 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 (items) between |
| square brackets. List items need not all have the same type. |
| |
| \bcode\begin{verbatim} |
| >>> a = ['foo', 'bar', 100, 1234] |
| >>> a |
| ['foo', 'bar', 100, 1234] |
| >>> |
| \end{verbatim}\ecode |
| % |
| Like string indices, list indices start at 0, and lists can be sliced, |
| concatenated and so on: |
| |
| \bcode\begin{verbatim} |
| >>> a[0] |
| 'foo' |
| >>> a[3] |
| 1234 |
| >>> a[-2] |
| 100 |
| >>> a[1:-1] |
| ['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 can 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] |
| >>> a[:0] = a # Insert (a copy of) itself at the beginning |
| >>> a |
| [123, 'bletch', 'xyzzy', 1234, 123, 'bletch', 'xyzzy', 1234] |
| >>> |
| \end{verbatim}\ecode |
| % |
| The built-in function {\tt len()} also applies to lists: |
| |
| \bcode\begin{verbatim} |
| >>> len(a) |
| 8 |
| >>> |
| \end{verbatim}\ecode |
| % |
| It is possible to nest lists (create lists containing other lists), |
| for example: |
| |
| \bcode\begin{verbatim} |
| >>> q = [2, 3] |
| >>> p = [1, q, 4] |
| >>> len(p) |
| 3 |
| >>> p[1] |
| [2, 3] |
| >>> p[1][0] |
| 2 |
| >>> p[1].append('xtra') # See section 5.1 |
| >>> p |
| [1, [2, 3, 'xtra'], 4] |
| >>> q |
| [2, 3, 'xtra'] |
| >>> |
| \end{verbatim}\ecode |
| % |
| Note that in the last example, {\tt p[1]} and {\tt q} really refer to |
| the same object! We'll come back to {\em object semantics} later. |
| |
| \section{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 < 10: |
| ... print b |
| ... a, b = b, a+b |
| ... |
| 1 |
| 1 |
| 2 |
| 3 |
| 5 |
| 8 |
| >>> |
| \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: {\tt b < |
| 100}) remains true. In Python, like 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 the same as |
| in C: {\tt <}, {\tt >}, {\tt ==}, {\tt <=}, {\tt >=} and {\tt !=}. |
| |
| \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} |
| |
| \chapter{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. |
| |
| \section{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. |
| |
| \section{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 (like in 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), in the order that they appear in the sequence. 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 |
| % |
| It is not safe to modify the sequence being iterated over in the loop |
| (this can only happen for mutable sequence types, i.e., lists). If |
| you need to modify the list you are iterating over, e.g., duplicate |
| selected items, you must iterate over a copy. The slice notation |
| makes this particularly convenient: |
| |
| \bcode\begin{verbatim} |
| >>> for x in a[:]: # make a slice copy of the entire list |
| ... if len(x) > 6: a.insert(0, x) |
| ... |
| >>> a |
| ['defenestrate', 'cat', 'window', 'defenestrate'] |
| >>> |
| \end{verbatim}\ecode |
| |
| \section{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', 'lamb'] |
| >>> for i in range(len(a)): |
| ... print i, a[i] |
| ... |
| 0 Mary |
| 1 had |
| 2 a |
| 3 little |
| 4 lamb |
| >>> |
| \end{verbatim}\ecode |
| |
| \section{Break and Continue Statements, and Else Clauses on Loops} |
| |
| The {\tt break} statement, like in C, breaks out of the smallest |
| enclosing {\tt for} or {\tt while} loop. |
| |
| The {\tt continue} statement, also borrowed from C, continues with the |
| next iteration of the 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 |
| |
| \section{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 |
| |
| \section{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; |
| whereas |
| 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, |
| global variables cannot be directly assigned to from within a |
| function, although they may be referenced. |
| |
| 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 |
| current |
| symbol table. The value |
| of the function name |
| 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, like 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), in |
| which case the {\tt None} value is returned. |
| |
| \item |
| The statement {\tt result.append(b)} calls a {\em method} of the list |
| object {\tt result}. 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. (It is possible to define your |
| own object types and methods, using {\em classes}. This is an |
| advanced feature that is not discussed in this tutorial.) |
| 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 |
| example |
| it is equivalent to {\tt result = result + [b]}, but more efficient. |
| |
| \end{itemize} |
| |
| \chapter{Odds and Ends} |
| |
| This chapter describes some things you've learned about already in |
| more detail, and adds some new things as well. |
| |
| \section{More on Lists} |
| |
| The list data type has some more methods. Here are all of the methods |
| of lists objects: |
| |
| \begin{description} |
| |
| \item[{\tt insert(i, x)}] |
| Insert 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 append(x)}] |
| Equivalent to {\tt a.insert(len(a), x)}. |
| |
| \item[{\tt index(x)}] |
| Return the index in the list of the first item whose value is {\tt x}. |
| It is an error if there is no such item. |
| |
| \item[{\tt remove(x)}] |
| Remove the first item from the list whose value is {\tt x}. |
| It is an error if there is no such item. |
| |
| \item[{\tt sort()}] |
| Sort the items of the list, in place. |
| |
| \item[{\tt reverse()}] |
| Reverse the elements of the list, in place. |
| |
| \end{description} |
| |
| An example that uses all list methods: |
| |
| \bcode\begin{verbatim} |
| >>> a = [66.6, 333, 333, 1, 1234.5] |
| >>> a.insert(2, -1) |
| >>> a.append(333) |
| >>> a |
| [66.6, 333, -1, 333, 1, 1234.5, 333] |
| >>> a.index(333) |
| 1 |
| >>> a.remove(333) |
| >>> a |
| [66.6, -1, 333, 1, 1234.5, 333] |
| >>> a.reverse() |
| >>> a |
| [333, 1234.5, 1, 333, -1, 66.6] |
| >>> a.sort() |
| >>> a |
| [-1, 1, 66.6, 333, 333, 1234.5] |
| >>> |
| \end{verbatim}\ecode |
| |
| \section{The {\tt del} statement} |
| |
| There is a way to remove an item from a list given its index instead |
| of its value: the {\tt del} statement. This can also be used to |
| remove slices from a list (which we did earlier by assignment of an |
| empty list to the slice). For example: |
| |
| \bcode\begin{verbatim} |
| >>> a |
| [-1, 1, 66.6, 333, 333, 1234.5] |
| >>> del a[0] |
| >>> a |
| [1, 66.6, 333, 333, 1234.5] |
| >>> del a[2:4] |
| >>> a |
| [1, 66.6, 1234.5] |
| >>> |
| \end{verbatim}\ecode |
| % |
| {\tt del} can also be used to delete entire variables: |
| |
| \bcode\begin{verbatim} |
| >>> del a |
| >>> |
| \end{verbatim}\ecode |
| % |
| Referencing the name {\tt a} hereafter is an error (at least until |
| another value is assigned to it). We'll find other uses for {\tt del} |
| later. |
| |
| \section{Tuples and Sequences} |
| |
| We saw that lists and strings have many common properties, e.g., |
| indexinging and slicing operations. They are two examples of {\em |
| sequence} data types. Since Python is an evolving language, other |
| sequence data types may be added. There is also another standard |
| sequence data type: the {\em tuple}. |
| |
| A tuple consists of a number of values separated by commas, for |
| instance: |
| |
| \bcode\begin{verbatim} |
| >>> t = 12345, 54321, 'hello!' |
| >>> t[0] |
| 12345 |
| >>> t |
| (12345, 54321, 'hello!') |
| >>> # Tuples may be nested: |
| >>> u = t, (1, 2, 3, 4, 5) |
| >>> u |
| ((12345, 54321, 'hello!'), (1, 2, 3, 4, 5)) |
| >>> |
| \end{verbatim}\ecode |
| % |
| As you see, on output tuples are alway enclosed in parentheses, so |
| that nested tuples are interpreted correctly; they may be input with |
| or without surrounding parentheses, although often parentheses are |
| necessary anyway (if the tuple is part of a larger expression). |
| |
| Tuples have many uses, e.g., (x, y) coordinate pairs, employee records |
| from a database, etc. Tuples, like strings, are immutable: it is not |
| possible to assign to the individual items of a tuple (you can |
| simulate much of the same effect with slicing and concatenation, |
| though). |
| |
| A special problem is the construction of tuples containing 0 or 1 |
| items: the syntax has some extra quirks to accomodate these. Empty |
| tuples are constructed by an empty pair of parentheses; a tuple with |
| one item is constructed by following a value with a comma |
| (it is not sufficient to enclose a single value in parentheses). |
| Ugly, but effective. For example: |
| |
| \bcode\begin{verbatim} |
| >>> empty = () |
| >>> singleton = 'hello', # <-- note trailing comma |
| >>> len(empty) |
| 0 |
| >>> len(singleton) |
| 1 |
| >>> singleton |
| ('hello',) |
| >>> |
| \end{verbatim}\ecode |
| % |
| The statement {\tt t = 12345, 54321, 'hello!'} is an example of {\em |
| tuple packing}: the values {\tt 12345}, {\tt 54321} and {\tt 'hello!'} |
| are packed together in a tuple. The reverse operation is also |
| possible, e.g.: |
| |
| \bcode\begin{verbatim} |
| >>> x, y, z = t |
| >>> |
| \end{verbatim}\ecode |
| % |
| This is called, appropriately enough, {\em tuple unpacking}. Tuple |
| unpacking requires that the list of variables on the left has the same |
| number of elements as the length of the tuple. Note that multiple |
| assignment is really just a combination of tuple packing and tuple |
| unpacking! |
| |
| Occasionally, the corresponding operation on lists is useful: {\em list |
| unpacking}. This is supported by enclosing the list of variables in |
| square brackets: |
| |
| \bcode\begin{verbatim} |
| >>> a = ['foo', 'bar', 100, 1234] |
| >>> [a1, a2, a3, a4] = a |
| >>> |
| \end{verbatim}\ecode |
| |
| \section{Dictionaries} |
| |
| Another useful data type built into Python is the {\em dictionary}. |
| Dictionaries are sometimes found in other languages as ``associative |
| memories'' or ``associative arrays''. Unlike sequences, which are |
| indexed by a range of numbers, dictionaries are indexed by {\em keys}, |
| which are strings. It is best to think of a dictionary as an unordered set of |
| {\em key:value} pairs, with the requirement that the keys are unique |
| (within one dictionary). |
| A pair of braces creates an empty dictionary: \verb/{}/. |
| Placing a comma-separated list of key:value pairs within the |
| braces adds initial key:value pairs to the dictionary; this is also the |
| way dictionaries are written on output. |
| |
| The main operations on a dictionary are storing a value with some key |
| and extracting the value given the key. It is also possible to delete |
| a key:value pair |
| with {\tt del}. |
| If you store using a key that is already in use, the old value |
| associated with that key is forgotten. It is an error to extract a |
| value using a non-existant key. |
| |
| The {\tt keys()} method of a dictionary object returns a list of all the |
| keys used in the dictionary, in random order (if you want it sorted, |
| just apply the {\tt sort()} method to the list of keys). To check |
| whether a single key is in the dictionary, use the \verb/has_key()/ |
| method of the dictionary. |
| |
| Here is a small example using a dictionary: |
| |
| \bcode\begin{verbatim} |
| >>> tel = {'jack': 4098, 'sape': 4139} |
| >>> tel['guido'] = 4127 |
| >>> tel |
| {'sape': 4139, 'guido': 4127, 'jack': 4098} |
| >>> tel['jack'] |
| 4098 |
| >>> del tel['sape'] |
| >>> tel['irv'] = 4127 |
| >>> tel |
| {'guido': 4127, 'irv': 4127, 'jack': 4098} |
| >>> tel.keys() |
| ['guido', 'irv', 'jack'] |
| >>> tel.has_key('guido') |
| 1 |
| >>> |
| \end{verbatim}\ecode |
| |
| \section{More on Conditions} |
| |
| The conditions used in {\tt while} and {\tt if} statements above can |
| contain other operators besides comparisons. |
| |
| The comparison operators {\tt in} and {\tt not in} check whether a value |
| occurs (does not occur) in a sequence. The operators {\tt is} and {\tt |
| is not} compare whether two objects are really the same object; this |
| only matters for mutable objects like lists. All comparison operators |
| have the same priority, which is lower than that of all numerical |
| operators. |
| |
| Comparisons can be chained: e.g., {\tt a < b = c} tests whether {\tt a} |
| is less than {\tt b} and moreover {\tt b} equals {\tt c}. |
| |
| Comparisons may be combined by the Boolean operators {\tt and} and {\tt |
| or}, and the outcome of a comparison (or of any other Boolean |
| expression) may be negated with {\tt not}. These all have lower |
| priorities than comparison operators again; between them, {\tt not} has |
| the highest priority, and {\tt or} the lowest, so that |
| {\tt A and not B or C} is equivalent to {\tt (A and (not B)) or C}. Of |
| course, parentheses can be used to express the desired composition. |
| |
| The Boolean operators {\tt and} and {\tt or} are so-called {\em |
| shortcut} operators: their arguments are evaluated from left to right, |
| and evaluation stops as soon as the outcome is determined. E.g., if |
| {\tt A} and {\tt C} are true but {\tt B} is false, {\tt A and B and C} |
| does not evaluate the expression C. In general, the return value of a |
| shortcut operator, when used as a general value and not as a Boolean, is |
| the last evaluated argument. |
| |
| It is possible to assign the result of a comparison or other Boolean |
| expression to a variable, but you must enclose the entire Boolean |
| expression in parentheses. This is necessary because otherwise an |
| assignment like \verb/a = b = c/ would be ambiguous: does it assign the |
| value of {\tt c} to {\tt a} and {\tt b}, or does it compare {\tt b} to |
| {\tt c} and assign the outcome (0 or 1) to {\tt a}? As it is, the first |
| meaning is what you get, and to get the latter you have to write |
| \verb/a = (b = c)/. (In Python, unlike C, assignment cannot occur |
| inside expressions.) |
| |
| \section{Comparing Sequences and Other Types} |
| |
| Sequence objects may be compared to other objects with the same |
| sequence type. The comparison uses {\em lexicographical} ordering: |
| first the first two items are compared, and if they differ this |
| determines the outcome of the comparison; if they are equal, the next |
| two items are compared, and so on, until either sequence is exhausted. |
| If two items to be compared are themselves sequences of the same type, |
| the lexiographical comparison is carried out recursively. If all |
| items of two sequences compare equal, the sequences are considered |
| equal. If one sequence is an initial subsequence of the other, the |
| shorted sequence is the smaller one. Lexicographical ordering for |
| strings uses the ASCII ordering for individual characters. Some |
| examples of comparisons between sequences with the same types: |
| |
| \bcode\begin{verbatim} |
| (1, 2, 3) < (1, 2, 4) |
| [1, 2, 3] < [1, 2, 4] |
| 'ABC' < 'C' < 'Pascal' < 'Python' |
| (1, 2, 3, 4) < (1, 2, 4) |
| (1, 2) < (1, 2, -1) |
| (1, 2, 3) = (1.0, 2.0, 3.0) |
| (1, 2, ('aa', 'ab')) < (1, 2, ('abc', 'a'), 4) |
| \end{verbatim}\ecode |
| % |
| Note that comparing objects of different types is legal. The outcome |
| is deterministic but arbitrary: the types are ordered by their name. |
| Thus, a list is always smaller than a string, a string is always |
| smaller than a tuple, etc. Mixed numeric types are compared according |
| to their numeric value, so 0 equals 0.0, etc.% |
| \footnote{ |
| The rules for comparing objects of different types should |
| not be relied upon; they may change in a future version of |
| the language. |
| } |
| |
| \chapter{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 |
| executed at the top level |
| 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 |
| result = [] |
| a, b = 0, 1 |
| while b <= n: |
| result.append(b) |
| a, b = b, a+b |
| return result |
| \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 current 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 |
| |
| \section{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 \_}). |
| |
| \section{Standard Modules} |
| |
| Python comes with a library of standard modules, described in a separate |
| document (Python Library 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 |
| |
| \section{The {\tt dir()} function} |
| |
| The built-in function {\tt dir} is used to find out which names a module |
| defines. It returns a sorted list of strings: |
| |
| \bcode\begin{verbatim} |
| >>> import fibo, sys |
| >>> dir(fibo) |
| ['fib', 'fib2'] |
| >>> dir(sys) |
| ['argv', 'exit', 'modules', 'path', 'ps1', 'ps2', 'stderr', 'stdin', 'stdout'] |
| >>> |
| \end{verbatim}\ecode |
| % |
| Without arguments, {\tt dir()} lists the names you have defined currently: |
| |
| \bcode\begin{verbatim} |
| >>> a = [1, 2, 3, 4, 5] |
| >>> import fibo, sys |
| >>> fib = fibo.fib |
| >>> dir() |
| ['a', 'fib', 'fibo', 'sys'] |
| >>> |
| \end{verbatim}\ecode |
| % |
| Note that it lists all types of names: variables, modules, functions, etc. |
| |
| {\tt dir()} does not list the names of built-in functions and variables. |
| If you want a list of those, they are defined in the standard module |
| {\tt builtin}: |
| |
| \bcode\begin{verbatim} |
| >>> import builtin |
| >>> dir(builtin) |
| ['EOFError', 'KeyboardInterrupt', 'MemoryError', 'NameError', 'None', 'Runti |
| meError', 'SystemError', 'TypeError', 'abs', 'chr', 'dir', 'divmod', 'eval', |
| 'exec', 'float', 'input', 'int', 'len', 'long', 'max', 'min', 'open', 'ord' |
| , 'pow', 'range', 'raw_input', 'reload', 'type'] |
| >>> |
| \end{verbatim}\ecode |
| |
| \chapter{Output Formatting} |
| |
| So far we've encountered two ways of writing values: {\em expression |
| statements} and the {\tt print} statement. (A third way is using the |
| {\tt write} method of file objects; the standard output file can be |
| referenced as {\tt sys.stdout}. See the Library Reference for more |
| information on this.) |
| |
| Often you'll want more control over the formatting of your output than |
| simply printing space-separated values. The key to nice formatting in |
| Python is to do all the string handling yourself; using string slicing |
| and concatenation operations you can create any lay-out you can imagine. |
| The standard module {\tt string} contains some useful operations for |
| padding strings to a given column width; these will be discussed shortly. |
| |
| One question remains, of course: how do you convert values to strings? |
| Luckily, Python has a way to convert any value to a string: just write |
| the value between reverse quotes (\verb/``/). Some examples: |
| |
| \bcode\begin{verbatim} |
| >>> x = 10 * 3.14 |
| >>> y = 200*200 |
| >>> s = 'The value of x is ' + `x` + ', and y is ' + `y` + '...' |
| >>> print s |
| The value of x is 31.4, and y is 40000... |
| >>> # Reverse quotes work on other types besides numbers: |
| >>> p = [x, y] |
| >>> ps = `p` |
| >>> ps |
| '[31.4, 40000]' |
| >>> # Converting a string adds string quotes and backslashes: |
| >>> hello = 'hello, world\n' |
| >>> hellos = `hello` |
| >>> print hellos |
| 'hello, world\012' |
| >>> # The argument of reverse quotes may be a tuple: |
| >>> `x, y, ('foo', 'bar')` |
| '(31.4, 40000, (\'foo\', \'bar\'))' |
| >>> |
| \end{verbatim}\ecode |
| % |
| Here is how you write a table of squares and cubes: |
| |
| \bcode\begin{verbatim} |
| >>> import string |
| >>> for x in range(1, 11): |
| ... print string.rjust(`x`, 2), string.rjust(`x*x`, 3), |
| ... # Note trailing comma on previous line |
| ... print string.rjust(`x*x*x`, 4) |
| ... |
| 1 1 1 |
| 2 4 8 |
| 3 9 27 |
| 4 16 64 |
| 5 25 125 |
| 6 36 216 |
| 7 49 343 |
| 8 64 512 |
| 9 81 729 |
| 10 100 1000 |
| >>> |
| \end{verbatim}\ecode |
| % |
| (Note that one space between each column was added by the way {\tt print} |
| works: it always adds spaces between its arguments.) |
| |
| This example demonstrates the function {\tt string.rjust()}, which |
| right-justifies a string in a field of a given width by padding it with |
| spaces on the left. There are similar functions {\tt string.ljust()} |
| and {\tt string.center()}. These functions do not write anything, they |
| just return a new string. If the input string is too long, they don't |
| truncate it, but return it unchanged; this will mess up your column |
| lay-out but that's usually better than the alternative, which would be |
| lying about a value. (If you really want truncation you can always add |
| a slice operation, as in {\tt string.ljust(x,~n)[0:n]}.) |
| |
| There is another function, {\tt string.zfill}, which pads a numeric |
| string on the left with zeros. It understands about plus and minus |
| signs:% |
| \footnote{ |
| Better facilities for formatting floating point numbers are |
| lacking at this moment. |
| } |
| |
| \bcode\begin{verbatim} |
| >>> string.zfill('12', 5) |
| '00012' |
| >>> string.zfill('-3.14', 7) |
| '-003.14' |
| >>> string.zfill('3.14159265359', 5) |
| '3.14159265359' |
| >>> |
| \end{verbatim}\ecode |
| |
| \chapter{Errors and Exceptions} |
| |
| Until now error messages haven't been more than 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}. |
| |
| \section{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. |
| |
| \section{Exceptions} |
| |
| Even if a statement or expression is syntactically correct, it may |
| cause an error when an attempt is made to execute it. |
| 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: |
| |
| \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 |
| % |
| 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; 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 gleaned from the object type(s) alone. The detail shows |
| in what context the error was detected. |
| \end{itemize} |
| |
| \section{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, 10] |
| >>> 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, |
| the rest of the clause is skipped. Then if |
| 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. |
| 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 |
| |
| \section{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. |
| |
| \section{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. |
| |
| \section{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, |
| or whether or not an exception is handled. |
| 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. |
| |
| \end{document} |