Added more cross-reference targets and tidied up list of useful handlers.
[python.git] / Doc / tutorial / controlflow.rst
blob95a6ea4d2cba3cc4020bb782e0397072a103cbf3
1 .. _tut-morecontrol:
3 ***********************
4 More Control Flow Tools
5 ***********************
7 Besides the :keyword:`while` statement just introduced, Python knows the usual
8 control flow statements known from other languages, with some twists.
11 .. _tut-if:
13 :keyword:`if` Statements
14 ========================
16 Perhaps the most well-known statement type is the :keyword:`if` statement.  For
17 example::
19    >>> x = int(raw_input("Please enter an integer: "))
20    Please enter an integer: 42
21    >>> if x < 0:
22    ...      x = 0
23    ...      print 'Negative changed to zero'
24    ... elif x == 0:
25    ...      print 'Zero'
26    ... elif x == 1:
27    ...      print 'Single'
28    ... else:
29    ...      print 'More'
30    ...
31    More
33 There can be zero or more :keyword:`elif` parts, and the :keyword:`else` part is
34 optional.  The keyword ':keyword:`elif`' is short for 'else if', and is useful
35 to avoid excessive indentation.  An  :keyword:`if` ... :keyword:`elif` ...
36 :keyword:`elif` ... sequence is a substitute for the ``switch`` or
37 ``case`` statements found in other languages.
40 .. _tut-for:
42 :keyword:`for` Statements
43 =========================
45 .. index::
46    statement: for
47    statement: for
49 The :keyword:`for` statement in Python differs a bit from what you may be used
50 to in C or Pascal.  Rather than always iterating over an arithmetic progression
51 of numbers (like in Pascal), or giving the user the ability to define both the
52 iteration step and halting condition (as C), Python's :keyword:`for` statement
53 iterates over the items of any sequence (a list or a string), in the order that
54 they appear in the sequence.  For example (no pun intended):
56 .. One suggestion was to give a real C example here, but that may only serve to
57    confuse non-C programmers.
61    >>> # Measure some strings:
62    ... a = ['cat', 'window', 'defenestrate']
63    >>> for x in a:
64    ...     print x, len(x)
65    ...
66    cat 3
67    window 6
68    defenestrate 12
70 It is not safe to modify the sequence being iterated over in the loop (this can
71 only happen for mutable sequence types, such as lists).  If you need to modify
72 the list you are iterating over (for example, to duplicate selected items) you
73 must iterate over a copy.  The slice notation makes this particularly
74 convenient::
76    >>> for x in a[:]: # make a slice copy of the entire list
77    ...    if len(x) > 6: a.insert(0, x)
78    ...
79    >>> a
80    ['defenestrate', 'cat', 'window', 'defenestrate']
83 .. _tut-range:
85 The :func:`range` Function
86 ==========================
88 If you do need to iterate over a sequence of numbers, the built-in function
89 :func:`range` comes in handy.  It generates lists containing arithmetic
90 progressions::
92    >>> range(10)
93    [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
95 The given end point is never part of the generated list; ``range(10)`` generates
96 a list of 10 values, the legal indices for items of a sequence of length 10.  It
97 is possible to let the range start at another number, or to specify a different
98 increment (even negative; sometimes this is called the 'step')::
100    >>> range(5, 10)
101    [5, 6, 7, 8, 9]
102    >>> range(0, 10, 3)
103    [0, 3, 6, 9]
104    >>> range(-10, -100, -30)
105    [-10, -40, -70]
107 To iterate over the indices of a sequence, you can combine :func:`range` and
108 :func:`len` as follows::
110    >>> a = ['Mary', 'had', 'a', 'little', 'lamb']
111    >>> for i in range(len(a)):
112    ...     print i, a[i]
113    ...
114    0 Mary
115    1 had
116    2 a
117    3 little
118    4 lamb
120 In most such cases, however, it is convenient to use the :func:`enumerate`
121 function, see :ref:`tut-loopidioms`.
124 .. _tut-break:
126 :keyword:`break` and :keyword:`continue` Statements, and :keyword:`else` Clauses on Loops
127 =========================================================================================
129 The :keyword:`break` statement, like in C, breaks out of the smallest enclosing
130 :keyword:`for` or :keyword:`while` loop.
132 The :keyword:`continue` statement, also borrowed from C, continues with the next
133 iteration of the loop.
135 Loop statements may have an ``else`` clause; it is executed when the loop
136 terminates through exhaustion of the list (with :keyword:`for`) or when the
137 condition becomes false (with :keyword:`while`), but not when the loop is
138 terminated by a :keyword:`break` statement.  This is exemplified by the
139 following loop, which searches for prime numbers::
141    >>> for n in range(2, 10):
142    ...     for x in range(2, n):
143    ...         if n % x == 0:
144    ...             print n, 'equals', x, '*', n/x
145    ...             break
146    ...     else:
147    ...         # loop fell through without finding a factor
148    ...         print n, 'is a prime number'
149    ...
150    2 is a prime number
151    3 is a prime number
152    4 equals 2 * 2
153    5 is a prime number
154    6 equals 2 * 3
155    7 is a prime number
156    8 equals 2 * 4
157    9 equals 3 * 3
160 .. _tut-pass:
162 :keyword:`pass` Statements
163 ==========================
165 The :keyword:`pass` statement does nothing. It can be used when a statement is
166 required syntactically but the program requires no action. For example::
168    >>> while True:
169    ...     pass  # Busy-wait for keyboard interrupt (Ctrl+C)
170    ...
172 This is commonly used for creating minimal classes::
174    >>> class MyEmptyClass:
175    ...     pass
176    ...
178 Another place :keyword:`pass` can be used is as a place-holder for a function or
179 conditional body when you are working on new code, allowing you to keep thinking
180 at a more abstract level.  The :keyword:`pass` is silently ignored::
182    >>> def initlog(*args):
183    ...     pass   # Remember to implement this!
184    ...
186 .. _tut-functions:
188 Defining Functions
189 ==================
191 We can create a function that writes the Fibonacci series to an arbitrary
192 boundary::
194    >>> def fib(n):    # write Fibonacci series up to n
195    ...     """Print a Fibonacci series up to n."""
196    ...     a, b = 0, 1
197    ...     while b < n:
198    ...         print b,
199    ...         a, b = b, a+b
200    ...
201    >>> # Now call the function we just defined:
202    ... fib(2000)
203    1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597
205 .. index::
206    single: documentation strings
207    single: docstrings
208    single: strings, documentation
210 The keyword :keyword:`def` introduces a function *definition*.  It must be
211 followed by the function name and the parenthesized list of formal parameters.
212 The statements that form the body of the function start at the next line, and
213 must be indented.
215 The first statement of the function body can optionally be a string literal;
216 this string literal is the function's documentation string, or :dfn:`docstring`.
217 (More about docstrings can be found in the section :ref:`tut-docstrings`.)
218 There are tools which use docstrings to automatically produce online or printed
219 documentation, or to let the user interactively browse through code; it's good
220 practice to include docstrings in code that you write, so make a habit of it.
222 The *execution* of a function introduces a new symbol table used for the local
223 variables of the function.  More precisely, all variable assignments in a
224 function store the value in the local symbol table; whereas variable references
225 first look in the local symbol table, then in the local symbol tables of
226 enclosing functions, then in the global symbol table, and finally in the table
227 of built-in names. Thus, global variables cannot be directly assigned a value
228 within a function (unless named in a :keyword:`global` statement), although they
229 may be referenced.
231 The actual parameters (arguments) to a function call are introduced in the local
232 symbol table of the called function when it is called; thus, arguments are
233 passed using *call by value* (where the *value* is always an object *reference*,
234 not the value of the object). [#]_ When a function calls another function, a new
235 local symbol table is created for that call.
237 A function definition introduces the function name in the current symbol table.
238 The value of the function name has a type that is recognized by the interpreter
239 as a user-defined function.  This value can be assigned to another name which
240 can then also be used as a function.  This serves as a general renaming
241 mechanism::
243    >>> fib
244    <function fib at 10042ed0>
245    >>> f = fib
246    >>> f(100)
247    1 1 2 3 5 8 13 21 34 55 89
249 Coming from other languages, you might object that ``fib`` is not a function but
250 a procedure since it doesn't return a value.  In fact, even functions without a
251 :keyword:`return` statement do return a value, albeit a rather boring one.  This
252 value is called ``None`` (it's a built-in name).  Writing the value ``None`` is
253 normally suppressed by the interpreter if it would be the only value written.
254 You can see it if you really want to using :keyword:`print`::
256    >>> fib(0)
257    >>> print fib(0)
258    None
260 It is simple to write a function that returns a list of the numbers of the
261 Fibonacci series, instead of printing it::
263    >>> def fib2(n): # return Fibonacci series up to n
264    ...     """Return a list containing the Fibonacci series up to n."""
265    ...     result = []
266    ...     a, b = 0, 1
267    ...     while b < n:
268    ...         result.append(b)    # see below
269    ...         a, b = b, a+b
270    ...     return result
271    ...
272    >>> f100 = fib2(100)    # call it
273    >>> f100                # write the result
274    [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
276 This example, as usual, demonstrates some new Python features:
278 * The :keyword:`return` statement returns with a value from a function.
279   :keyword:`return` without an expression argument returns ``None``. Falling off
280   the end of a function also returns ``None``.
282 * The statement ``result.append(b)`` calls a *method* of the list object
283   ``result``.  A method is a function that 'belongs' to an object and is named
284   ``obj.methodname``, where ``obj`` is some object (this may be an expression),
285   and ``methodname`` is the name of a method that is defined by the object's type.
286   Different types define different methods.  Methods of different types may have
287   the same name without causing ambiguity.  (It is possible to define your own
288   object types and methods, using *classes*, as discussed later in this tutorial.)
289   The method :meth:`append` shown in the example is defined for list objects; it
290   adds a new element at the end of the list.  In this example it is equivalent to
291   ``result = result + [b]``, but more efficient.
294 .. _tut-defining:
296 More on Defining Functions
297 ==========================
299 It is also possible to define functions with a variable number of arguments.
300 There are three forms, which can be combined.
303 .. _tut-defaultargs:
305 Default Argument Values
306 -----------------------
308 The most useful form is to specify a default value for one or more arguments.
309 This creates a function that can be called with fewer arguments than it is
310 defined to allow.  For example::
312    def ask_ok(prompt, retries=4, complaint='Yes or no, please!'):
313        while True:
314            ok = raw_input(prompt)
315            if ok in ('y', 'ye', 'yes'): return True
316            if ok in ('n', 'no', 'nop', 'nope'): return False
317            retries = retries - 1
318            if retries < 0: raise IOError, 'refusenik user'
319            print complaint
321 This function can be called either like this: ``ask_ok('Do you really want to
322 quit?')`` or like this: ``ask_ok('OK to overwrite the file?', 2)``.
324 This example also introduces the :keyword:`in` keyword. This tests whether or
325 not a sequence contains a certain value.
327 The default values are evaluated at the point of function definition in the
328 *defining* scope, so that ::
330    i = 5
332    def f(arg=i):
333        print arg
335    i = 6
336    f()
338 will print ``5``.
340 **Important warning:**  The default value is evaluated only once. This makes a
341 difference when the default is a mutable object such as a list, dictionary, or
342 instances of most classes.  For example, the following function accumulates the
343 arguments passed to it on subsequent calls::
345    def f(a, L=[]):
346        L.append(a)
347        return L
349    print f(1)
350    print f(2)
351    print f(3)
353 This will print ::
355    [1]
356    [1, 2]
357    [1, 2, 3]
359 If you don't want the default to be shared between subsequent calls, you can
360 write the function like this instead::
362    def f(a, L=None):
363        if L is None:
364            L = []
365        L.append(a)
366        return L
369 .. _tut-keywordargs:
371 Keyword Arguments
372 -----------------
374 Functions can also be called using keyword arguments of the form ``keyword =
375 value``.  For instance, the following function::
377    def parrot(voltage, state='a stiff', action='voom', type='Norwegian Blue'):
378        print "-- This parrot wouldn't", action,
379        print "if you put", voltage, "volts through it."
380        print "-- Lovely plumage, the", type
381        print "-- It's", state, "!"
383 could be called in any of the following ways::
385    parrot(1000)
386    parrot(action = 'VOOOOOM', voltage = 1000000)
387    parrot('a thousand', state = 'pushing up the daisies')
388    parrot('a million', 'bereft of life', 'jump')
390 but the following calls would all be invalid::
392    parrot()                     # required argument missing
393    parrot(voltage=5.0, 'dead')  # non-keyword argument following keyword
394    parrot(110, voltage=220)     # duplicate value for argument
395    parrot(actor='John Cleese')  # unknown keyword
397 In general, an argument list must have any positional arguments followed by any
398 keyword arguments, where the keywords must be chosen from the formal parameter
399 names.  It's not important whether a formal parameter has a default value or
400 not.  No argument may receive a value more than once --- formal parameter names
401 corresponding to positional arguments cannot be used as keywords in the same
402 calls. Here's an example that fails due to this restriction::
404    >>> def function(a):
405    ...     pass
406    ...
407    >>> function(0, a=0)
408    Traceback (most recent call last):
409      File "<stdin>", line 1, in ?
410    TypeError: function() got multiple values for keyword argument 'a'
412 When a final formal parameter of the form ``**name`` is present, it receives a
413 dictionary (see :ref:`typesmapping`) containing all keyword arguments except for
414 those corresponding to a formal parameter.  This may be combined with a formal
415 parameter of the form ``*name`` (described in the next subsection) which
416 receives a tuple containing the positional arguments beyond the formal parameter
417 list.  (``*name`` must occur before ``**name``.) For example, if we define a
418 function like this::
420    def cheeseshop(kind, *arguments, **keywords):
421        print "-- Do you have any", kind, "?"
422        print "-- I'm sorry, we're all out of", kind
423        for arg in arguments: print arg
424        print "-" * 40
425        keys = keywords.keys()
426        keys.sort()
427        for kw in keys: print kw, ":", keywords[kw]
429 It could be called like this::
431    cheeseshop("Limburger", "It's very runny, sir.",
432               "It's really very, VERY runny, sir.",
433               shopkeeper='Michael Palin',
434               client="John Cleese",
435               sketch="Cheese Shop Sketch")
437 and of course it would print::
439    -- Do you have any Limburger ?
440    -- I'm sorry, we're all out of Limburger
441    It's very runny, sir.
442    It's really very, VERY runny, sir.
443    ----------------------------------------
444    client : John Cleese
445    shopkeeper : Michael Palin
446    sketch : Cheese Shop Sketch
448 Note that the :meth:`sort` method of the list of keyword argument names is
449 called before printing the contents of the ``keywords`` dictionary; if this is
450 not done, the order in which the arguments are printed is undefined.
453 .. _tut-arbitraryargs:
455 Arbitrary Argument Lists
456 ------------------------
458 .. index::
459   statement: *
461 Finally, the least frequently used option is to specify that a function can be
462 called with an arbitrary number of arguments.  These arguments will be wrapped
463 up in a tuple (see :ref:`tut-tuples`).  Before the variable number of arguments,
464 zero or more normal arguments may occur. ::
466    def write_multiple_items(file, separator, *args):
467        file.write(separator.join(args))
470 .. _tut-unpacking-arguments:
472 Unpacking Argument Lists
473 ------------------------
475 The reverse situation occurs when the arguments are already in a list or tuple
476 but need to be unpacked for a function call requiring separate positional
477 arguments.  For instance, the built-in :func:`range` function expects separate
478 *start* and *stop* arguments.  If they are not available separately, write the
479 function call with the  ``*``\ -operator to unpack the arguments out of a list
480 or tuple::
482    >>> range(3, 6)             # normal call with separate arguments
483    [3, 4, 5]
484    >>> args = [3, 6]
485    >>> range(*args)            # call with arguments unpacked from a list
486    [3, 4, 5]
488 .. index::
489   statement: **
491 In the same fashion, dictionaries can deliver keyword arguments with the ``**``\
492 -operator::
494    >>> def parrot(voltage, state='a stiff', action='voom'):
495    ...     print "-- This parrot wouldn't", action,
496    ...     print "if you put", voltage, "volts through it.",
497    ...     print "E's", state, "!"
498    ...
499    >>> d = {"voltage": "four million", "state": "bleedin' demised", "action": "VOOM"}
500    >>> parrot(**d)
501    -- This parrot wouldn't VOOM if you put four million volts through it. E's bleedin' demised !
504 .. _tut-lambda:
506 Lambda Forms
507 ------------
509 By popular demand, a few features commonly found in functional programming
510 languages like Lisp have been added to Python.  With the :keyword:`lambda`
511 keyword, small anonymous functions can be created. Here's a function that
512 returns the sum of its two arguments: ``lambda a, b: a+b``.  Lambda forms can be
513 used wherever function objects are required.  They are syntactically restricted
514 to a single expression.  Semantically, they are just syntactic sugar for a
515 normal function definition.  Like nested function definitions, lambda forms can
516 reference variables from the containing scope::
518    >>> def make_incrementor(n):
519    ...     return lambda x: x + n
520    ...
521    >>> f = make_incrementor(42)
522    >>> f(0)
523    42
524    >>> f(1)
525    43
528 .. _tut-docstrings:
530 Documentation Strings
531 ---------------------
533 .. index::
534    single: docstrings
535    single: documentation strings
536    single: strings, documentation
538 There are emerging conventions about the content and formatting of documentation
539 strings.
541 The first line should always be a short, concise summary of the object's
542 purpose.  For brevity, it should not explicitly state the object's name or type,
543 since these are available by other means (except if the name happens to be a
544 verb describing a function's operation).  This line should begin with a capital
545 letter and end with a period.
547 If there are more lines in the documentation string, the second line should be
548 blank, visually separating the summary from the rest of the description.  The
549 following lines should be one or more paragraphs describing the object's calling
550 conventions, its side effects, etc.
552 The Python parser does not strip indentation from multi-line string literals in
553 Python, so tools that process documentation have to strip indentation if
554 desired.  This is done using the following convention. The first non-blank line
555 *after* the first line of the string determines the amount of indentation for
556 the entire documentation string.  (We can't use the first line since it is
557 generally adjacent to the string's opening quotes so its indentation is not
558 apparent in the string literal.)  Whitespace "equivalent" to this indentation is
559 then stripped from the start of all lines of the string.  Lines that are
560 indented less should not occur, but if they occur all their leading whitespace
561 should be stripped.  Equivalence of whitespace should be tested after expansion
562 of tabs (to 8 spaces, normally).
564 Here is an example of a multi-line docstring::
566    >>> def my_function():
567    ...     """Do nothing, but document it.
568    ...
569    ...     No, really, it doesn't do anything.
570    ...     """
571    ...     pass
572    ...
573    >>> print my_function.__doc__
574    Do nothing, but document it.
576        No, really, it doesn't do anything.
579 .. _tut-codingstyle:
581 Intermezzo: Coding Style
582 ========================
584 .. sectionauthor:: Georg Brandl <georg@python.org>
585 .. index:: pair: coding; style
587 Now that you are about to write longer, more complex pieces of Python, it is a
588 good time to talk about *coding style*.  Most languages can be written (or more
589 concise, *formatted*) in different styles; some are more readable than others.
590 Making it easy for others to read your code is always a good idea, and adopting
591 a nice coding style helps tremendously for that.
593 For Python, :pep:`8` has emerged as the style guide that most projects adhere to;
594 it promotes a very readable and eye-pleasing coding style.  Every Python
595 developer should read it at some point; here are the most important points
596 extracted for you:
598 * Use 4-space indentation, and no tabs.
600   4 spaces are a good compromise between small indentation (allows greater
601   nesting depth) and large indentation (easier to read).  Tabs introduce
602   confusion, and are best left out.
604 * Wrap lines so that they don't exceed 79 characters.
606   This helps users with small displays and makes it possible to have several
607   code files side-by-side on larger displays.
609 * Use blank lines to separate functions and classes, and larger blocks of
610   code inside functions.
612 * When possible, put comments on a line of their own.
614 * Use docstrings.
616 * Use spaces around operators and after commas, but not directly inside
617   bracketing constructs: ``a = f(1, 2) + g(3, 4)``.
619 * Name your classes and functions consistently; the convention is to use
620   ``CamelCase`` for classes and ``lower_case_with_underscores`` for functions
621   and methods.  Always use ``self`` as the name for the first method argument
622   (see :ref:`tut-firstclasses` for more on classes and methods).
624 * Don't use fancy encodings if your code is meant to be used in international
625   environments.  Plain ASCII works best in any case.
628 .. rubric:: Footnotes
630 .. [#] Actually, *call by object reference* would be a better description,
631    since if a mutable object is passed, the caller will see any changes the
632    callee makes to it (items inserted into a list).