2007-08-15 11:28:01 -03:00
|
|
|
.. _tut-morecontrol:
|
|
|
|
|
|
|
|
***********************
|
|
|
|
More Control Flow Tools
|
|
|
|
***********************
|
|
|
|
|
|
|
|
Besides the :keyword:`while` statement just introduced, Python knows the usual
|
|
|
|
control flow statements known from other languages, with some twists.
|
|
|
|
|
|
|
|
|
|
|
|
.. _tut-if:
|
|
|
|
|
|
|
|
:keyword:`if` Statements
|
|
|
|
========================
|
|
|
|
|
|
|
|
Perhaps the most well-known statement type is the :keyword:`if` statement. For
|
|
|
|
example::
|
|
|
|
|
|
|
|
>>> x = int(raw_input("Please enter an integer: "))
|
2008-09-13 14:18:11 -03:00
|
|
|
Please enter an integer: 42
|
2007-08-15 11:28:01 -03:00
|
|
|
>>> if x < 0:
|
|
|
|
... x = 0
|
|
|
|
... print 'Negative changed to zero'
|
|
|
|
... elif x == 0:
|
|
|
|
... print 'Zero'
|
|
|
|
... elif x == 1:
|
|
|
|
... print 'Single'
|
|
|
|
... else:
|
|
|
|
... print 'More'
|
2008-09-13 14:18:11 -03:00
|
|
|
...
|
|
|
|
More
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
There can be zero or more :keyword:`elif` parts, and the :keyword:`else` part is
|
|
|
|
optional. The keyword ':keyword:`elif`' is short for 'else if', and is useful
|
|
|
|
to avoid excessive indentation. An :keyword:`if` ... :keyword:`elif` ...
|
2007-12-29 06:57:00 -04:00
|
|
|
:keyword:`elif` ... sequence is a substitute for the ``switch`` or
|
|
|
|
``case`` statements found in other languages.
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
|
|
|
|
.. _tut-for:
|
|
|
|
|
|
|
|
:keyword:`for` Statements
|
|
|
|
=========================
|
|
|
|
|
|
|
|
.. index::
|
|
|
|
statement: for
|
|
|
|
statement: for
|
|
|
|
|
|
|
|
The :keyword:`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 giving the user the ability to define both the
|
|
|
|
iteration step and halting condition (as C), Python's :keyword:`for` statement
|
|
|
|
iterates over the items of any sequence (a list or a string), in the order that
|
|
|
|
they appear in the sequence. For example (no pun intended):
|
|
|
|
|
2007-12-29 06:57:00 -04:00
|
|
|
.. One suggestion was to give a real C example here, but that may only serve to
|
|
|
|
confuse non-C programmers.
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
>>> # Measure some strings:
|
|
|
|
... a = ['cat', 'window', 'defenestrate']
|
|
|
|
>>> for x in a:
|
|
|
|
... print x, len(x)
|
|
|
|
...
|
|
|
|
cat 3
|
|
|
|
window 6
|
|
|
|
defenestrate 12
|
|
|
|
|
|
|
|
It is not safe to modify the sequence being iterated over in the loop (this can
|
|
|
|
only happen for mutable sequence types, such as lists). If you need to modify
|
|
|
|
the list you are iterating over (for example, to duplicate selected items) you
|
|
|
|
must iterate over a copy. The slice notation makes this particularly
|
|
|
|
convenient::
|
|
|
|
|
|
|
|
>>> 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']
|
|
|
|
|
|
|
|
|
|
|
|
.. _tut-range:
|
|
|
|
|
|
|
|
The :func:`range` Function
|
|
|
|
==========================
|
|
|
|
|
|
|
|
If you do need to iterate over a sequence of numbers, the built-in function
|
|
|
|
:func:`range` comes in handy. It generates lists containing arithmetic
|
|
|
|
progressions::
|
|
|
|
|
|
|
|
>>> range(10)
|
|
|
|
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
|
|
|
|
|
|
|
|
The given end point is never part of the generated list; ``range(10)`` generates
|
|
|
|
a list of 10 values, 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; sometimes this is called the 'step')::
|
|
|
|
|
|
|
|
>>> range(5, 10)
|
|
|
|
[5, 6, 7, 8, 9]
|
|
|
|
>>> range(0, 10, 3)
|
|
|
|
[0, 3, 6, 9]
|
|
|
|
>>> range(-10, -100, -30)
|
|
|
|
[-10, -40, -70]
|
|
|
|
|
Merged revisions 67326,67498,67531-67532,67538,67553-67554,67556-67557 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r67326 | benjamin.peterson | 2008-11-22 02:59:15 +0100 (Sat, 22 Nov 2008) | 1 line
backport r67325: make FileIO.mode always contain 'b'
........
r67498 | raymond.hettinger | 2008-12-03 16:42:10 +0100 (Wed, 03 Dec 2008) | 1 line
Backport r67478
........
r67531 | georg.brandl | 2008-12-04 19:54:05 +0100 (Thu, 04 Dec 2008) | 2 lines
Add reference to enumerate() to indices example.
........
r67532 | georg.brandl | 2008-12-04 19:59:16 +0100 (Thu, 04 Dec 2008) | 2 lines
Add another heapq example.
........
r67538 | georg.brandl | 2008-12-04 22:28:16 +0100 (Thu, 04 Dec 2008) | 2 lines
Clarification to avoid confusing output with file descriptors.
........
r67553 | georg.brandl | 2008-12-05 08:49:49 +0100 (Fri, 05 Dec 2008) | 2 lines
#4408: document regex.groups.
........
r67554 | georg.brandl | 2008-12-05 08:52:26 +0100 (Fri, 05 Dec 2008) | 2 lines
#4409: fix asterisks looking like footnotes.
........
r67556 | georg.brandl | 2008-12-05 09:02:17 +0100 (Fri, 05 Dec 2008) | 2 lines
#4441: improve doc for os.open() flags.
........
r67557 | georg.brandl | 2008-12-05 09:06:57 +0100 (Fri, 05 Dec 2008) | 2 lines
Add an index entry for "subclassing immutable types".
........
2008-12-05 05:08:28 -04:00
|
|
|
To iterate over the indices of a sequence, you can combine :func:`range` and
|
|
|
|
:func:`len` as follows::
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
>>> 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
|
|
|
|
|
Merged revisions 67326,67498,67531-67532,67538,67553-67554,67556-67557 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r67326 | benjamin.peterson | 2008-11-22 02:59:15 +0100 (Sat, 22 Nov 2008) | 1 line
backport r67325: make FileIO.mode always contain 'b'
........
r67498 | raymond.hettinger | 2008-12-03 16:42:10 +0100 (Wed, 03 Dec 2008) | 1 line
Backport r67478
........
r67531 | georg.brandl | 2008-12-04 19:54:05 +0100 (Thu, 04 Dec 2008) | 2 lines
Add reference to enumerate() to indices example.
........
r67532 | georg.brandl | 2008-12-04 19:59:16 +0100 (Thu, 04 Dec 2008) | 2 lines
Add another heapq example.
........
r67538 | georg.brandl | 2008-12-04 22:28:16 +0100 (Thu, 04 Dec 2008) | 2 lines
Clarification to avoid confusing output with file descriptors.
........
r67553 | georg.brandl | 2008-12-05 08:49:49 +0100 (Fri, 05 Dec 2008) | 2 lines
#4408: document regex.groups.
........
r67554 | georg.brandl | 2008-12-05 08:52:26 +0100 (Fri, 05 Dec 2008) | 2 lines
#4409: fix asterisks looking like footnotes.
........
r67556 | georg.brandl | 2008-12-05 09:02:17 +0100 (Fri, 05 Dec 2008) | 2 lines
#4441: improve doc for os.open() flags.
........
r67557 | georg.brandl | 2008-12-05 09:06:57 +0100 (Fri, 05 Dec 2008) | 2 lines
Add an index entry for "subclassing immutable types".
........
2008-12-05 05:08:28 -04:00
|
|
|
In most such cases, however, it is convenient to use the :func:`enumerate`
|
|
|
|
function, see :ref:`tut-loopidioms`.
|
|
|
|
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
.. _tut-break:
|
|
|
|
|
|
|
|
:keyword:`break` and :keyword:`continue` Statements, and :keyword:`else` Clauses on Loops
|
|
|
|
=========================================================================================
|
|
|
|
|
|
|
|
The :keyword:`break` statement, like in C, breaks out of the smallest enclosing
|
|
|
|
:keyword:`for` or :keyword:`while` loop.
|
|
|
|
|
|
|
|
The :keyword:`continue` statement, also borrowed from C, continues with the next
|
|
|
|
iteration of the loop.
|
|
|
|
|
|
|
|
Loop statements may have an ``else`` clause; it is executed when the loop
|
|
|
|
terminates through exhaustion of the list (with :keyword:`for`) or when the
|
|
|
|
condition becomes false (with :keyword:`while`), but not when the loop is
|
|
|
|
terminated by a :keyword:`break` statement. This is exemplified by the
|
|
|
|
following loop, which searches for prime numbers::
|
|
|
|
|
|
|
|
>>> for n in range(2, 10):
|
|
|
|
... for x in range(2, n):
|
|
|
|
... if n % x == 0:
|
|
|
|
... print n, 'equals', x, '*', n/x
|
|
|
|
... break
|
2008-08-02 00:05:11 -03:00
|
|
|
... else:
|
|
|
|
... # loop fell through without finding a factor
|
|
|
|
... print n, 'is a prime number'
|
2007-08-15 11:28:01 -03:00
|
|
|
...
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
.. _tut-pass:
|
|
|
|
|
|
|
|
:keyword:`pass` Statements
|
|
|
|
==========================
|
|
|
|
|
|
|
|
The :keyword:`pass` statement does nothing. It can be used when a statement is
|
|
|
|
required syntactically but the program requires no action. For example::
|
|
|
|
|
|
|
|
>>> while True:
|
2008-09-13 14:18:11 -03:00
|
|
|
... pass # Busy-wait for keyboard interrupt (Ctrl+C)
|
2007-08-15 11:28:01 -03:00
|
|
|
...
|
|
|
|
|
Merged revisions 66801,66803-66804,66813,66854-66856,66866,66870-66872,66874,66887,66903,66905,66911,66913,66927,66932,66938,66942,66962,66964,66973-66974,66977,66992,66998-66999,67002,67005,67007,67028,67040-67041,67044,67070,67089,67091,67101,67117-67119,67123-67124 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
................
r66801 | andrew.kuchling | 2008-10-04 23:51:59 +0200 (Sat, 04 Oct 2008) | 1 line
Punctuation fix; expand dict.update docstring to be clearer
................
r66803 | benjamin.peterson | 2008-10-05 00:15:31 +0200 (Sun, 05 Oct 2008) | 1 line
fix typo
................
r66804 | andrew.kuchling | 2008-10-05 02:11:56 +0200 (Sun, 05 Oct 2008) | 1 line
#1415508 from Rocky Bernstein: add docstrings for enable_interspersed_args(), disable_interspersed_args()
................
r66813 | andrew.kuchling | 2008-10-06 14:07:04 +0200 (Mon, 06 Oct 2008) | 3 lines
Per Greg Ward, optparse is no longer being externally maintained.
I'll look at the bugs in the Optik bug tracker and copy them to the Python bug
tracker if they're still relevant.
................
r66854 | georg.brandl | 2008-10-08 19:20:20 +0200 (Wed, 08 Oct 2008) | 2 lines
#4059: patch up some sqlite docs.
................
r66855 | georg.brandl | 2008-10-08 19:30:55 +0200 (Wed, 08 Oct 2008) | 2 lines
#4058: fix some whatsnew markup.
................
r66856 | georg.brandl | 2008-10-08 20:47:17 +0200 (Wed, 08 Oct 2008) | 3 lines
#3935: properly support list subclasses in the C impl. of bisect.
Patch reviewed by Raymond.
................
r66866 | benjamin.peterson | 2008-10-09 22:54:43 +0200 (Thu, 09 Oct 2008) | 1 line
update paragraph about __future__ for 2.6
................
r66870 | armin.rigo | 2008-10-10 10:40:44 +0200 (Fri, 10 Oct 2008) | 2 lines
Typo: "ThreadError" is the name in the C source.
................
r66871 | benjamin.peterson | 2008-10-10 22:38:49 +0200 (Fri, 10 Oct 2008) | 1 line
fix a small typo
................
r66872 | benjamin.peterson | 2008-10-10 22:51:37 +0200 (Fri, 10 Oct 2008) | 1 line
talk about how you can unzip with zip
................
r66874 | benjamin.peterson | 2008-10-11 00:23:41 +0200 (Sat, 11 Oct 2008) | 1 line
PyGILState_Acquire -> PyGILState_Ensure
................
r66887 | benjamin.peterson | 2008-10-13 23:51:40 +0200 (Mon, 13 Oct 2008) | 1 line
document how to disable fixers
................
r66903 | benjamin.peterson | 2008-10-15 22:34:09 +0200 (Wed, 15 Oct 2008) | 1 line
don't recurse into directories that start with '.'
................
r66905 | benjamin.peterson | 2008-10-15 23:05:55 +0200 (Wed, 15 Oct 2008) | 1 line
support the optional line argument for idle
................
r66911 | benjamin.peterson | 2008-10-16 01:10:28 +0200 (Thu, 16 Oct 2008) | 41 lines
Merged revisions 66805,66841,66860,66884-66886,66893,66907,66910 via svnmerge from
svn+ssh://pythondev@svn.python.org/sandbox/trunk/2to3/lib2to3
........
r66805 | benjamin.peterson | 2008-10-04 20:11:02 -0500 (Sat, 04 Oct 2008) | 1 line
mention what the fixes directory is for
........
r66841 | benjamin.peterson | 2008-10-07 17:48:12 -0500 (Tue, 07 Oct 2008) | 1 line
use assertFalse and assertTrue
........
r66860 | benjamin.peterson | 2008-10-08 16:05:07 -0500 (Wed, 08 Oct 2008) | 1 line
instead of abusing the pattern matcher, use start_tree to find a next binding
........
r66884 | benjamin.peterson | 2008-10-13 15:50:30 -0500 (Mon, 13 Oct 2008) | 1 line
don't print tokens to stdout when -v is given
........
r66885 | benjamin.peterson | 2008-10-13 16:28:57 -0500 (Mon, 13 Oct 2008) | 1 line
add the -x option to disable fixers
........
r66886 | benjamin.peterson | 2008-10-13 16:33:53 -0500 (Mon, 13 Oct 2008) | 1 line
cut down on some crud
........
r66893 | benjamin.peterson | 2008-10-14 17:16:54 -0500 (Tue, 14 Oct 2008) | 1 line
add an optional set literal fixer
........
r66907 | benjamin.peterson | 2008-10-15 16:59:41 -0500 (Wed, 15 Oct 2008) | 1 line
don't write backup files by default
........
r66910 | benjamin.peterson | 2008-10-15 17:43:10 -0500 (Wed, 15 Oct 2008) | 1 line
add the -n option; it stops backupfiles from being written
........
................
r66913 | benjamin.peterson | 2008-10-16 20:52:14 +0200 (Thu, 16 Oct 2008) | 1 line
document that deque indexing is O(n) #4123
................
r66927 | andrew.kuchling | 2008-10-16 22:15:47 +0200 (Thu, 16 Oct 2008) | 1 line
Fix wording (2.6.1 backport candidate)
................
r66932 | benjamin.peterson | 2008-10-16 23:09:28 +0200 (Thu, 16 Oct 2008) | 1 line
check for error conditions in _json #3623
................
r66938 | benjamin.peterson | 2008-10-16 23:27:54 +0200 (Thu, 16 Oct 2008) | 1 line
fix possible ref leak
................
r66942 | benjamin.peterson | 2008-10-16 23:48:06 +0200 (Thu, 16 Oct 2008) | 1 line
fix more possible ref leaks in _json and use Py_CLEAR
................
r66962 | benjamin.peterson | 2008-10-17 22:01:01 +0200 (Fri, 17 Oct 2008) | 1 line
clarify CALL_FUNCTION #4141
................
r66964 | georg.brandl | 2008-10-17 23:41:49 +0200 (Fri, 17 Oct 2008) | 2 lines
Fix duplicate word.
................
r66973 | armin.ronacher | 2008-10-19 10:27:43 +0200 (Sun, 19 Oct 2008) | 3 lines
Fixed #4067 by implementing _attributes and _fields for the AST root node.
................
r66974 | benjamin.peterson | 2008-10-19 15:59:01 +0200 (Sun, 19 Oct 2008) | 1 line
fix compiler warning
................
r66977 | benjamin.peterson | 2008-10-19 21:39:16 +0200 (Sun, 19 Oct 2008) | 1 line
mention -n
................
r66992 | benjamin.peterson | 2008-10-21 22:51:13 +0200 (Tue, 21 Oct 2008) | 1 line
make sure to call iteritems()
................
r66998 | benjamin.peterson | 2008-10-22 22:57:43 +0200 (Wed, 22 Oct 2008) | 1 line
fix a few typos
................
r66999 | benjamin.peterson | 2008-10-22 23:05:30 +0200 (Wed, 22 Oct 2008) | 1 line
and another typo...
................
r67002 | hirokazu.yamamoto | 2008-10-23 02:37:33 +0200 (Thu, 23 Oct 2008) | 1 line
Issue #4183: Some tests didn't run with pickle.HIGHEST_PROTOCOL.
................
r67005 | walter.doerwald | 2008-10-23 15:11:39 +0200 (Thu, 23 Oct 2008) | 2 lines
Use the correct names of the stateless codec functions (Fixes issue 4178).
................
r67007 | benjamin.peterson | 2008-10-23 23:43:48 +0200 (Thu, 23 Oct 2008) | 1 line
only nonempty __slots__ don't work
................
r67028 | benjamin.peterson | 2008-10-26 01:27:07 +0200 (Sun, 26 Oct 2008) | 1 line
don't use a catch-all
................
r67040 | armin.rigo | 2008-10-28 18:01:21 +0100 (Tue, 28 Oct 2008) | 5 lines
Fix one of the tests: it relied on being present in an "output test" in
order to actually test what it was supposed to test, i.e. that the code
in the __del__ method did not crash. Use instead the new helper
test_support.captured_output().
................
r67041 | benjamin.peterson | 2008-10-29 21:33:00 +0100 (Wed, 29 Oct 2008) | 1 line
mention the version gettempdir() was added
................
r67044 | amaury.forgeotdarc | 2008-10-30 00:15:57 +0100 (Thu, 30 Oct 2008) | 3 lines
Correct error message in io.open():
closefd=True is the only accepted value with a file name.
................
r67070 | benjamin.peterson | 2008-10-31 21:41:44 +0100 (Fri, 31 Oct 2008) | 1 line
rephrase has_key doc
................
r67089 | benjamin.peterson | 2008-11-03 21:43:20 +0100 (Mon, 03 Nov 2008) | 1 line
clarify by splitting into multiple paragraphs
................
r67091 | benjamin.peterson | 2008-11-03 23:34:57 +0100 (Mon, 03 Nov 2008) | 1 line
move a FileIO test to test_fileio
................
r67101 | georg.brandl | 2008-11-04 21:49:35 +0100 (Tue, 04 Nov 2008) | 2 lines
#4167: fix markup glitches.
................
r67117 | georg.brandl | 2008-11-06 11:17:58 +0100 (Thu, 06 Nov 2008) | 2 lines
#4268: Use correct module for two toplevel functions.
................
r67118 | georg.brandl | 2008-11-06 11:19:11 +0100 (Thu, 06 Nov 2008) | 2 lines
#4267: small fixes in sqlite3 docs.
................
r67119 | georg.brandl | 2008-11-06 11:20:49 +0100 (Thu, 06 Nov 2008) | 2 lines
#4245: move Thread section to the top.
................
r67123 | georg.brandl | 2008-11-06 19:49:15 +0100 (Thu, 06 Nov 2008) | 2 lines
#4247: add "pass" examples to tutorial.
................
r67124 | andrew.kuchling | 2008-11-06 20:23:02 +0100 (Thu, 06 Nov 2008) | 1 line
Fix grammar error; reword two paragraphs
................
2008-11-07 04:56:27 -04:00
|
|
|
This is commonly used for creating minimal classes such as exceptions, or
|
|
|
|
for ignoring unwanted exceptions::
|
|
|
|
|
|
|
|
>>> class ParserError(Exception):
|
|
|
|
... pass
|
|
|
|
...
|
|
|
|
>>> try:
|
|
|
|
... import audioop
|
|
|
|
... except ImportError:
|
|
|
|
... pass
|
|
|
|
...
|
|
|
|
|
|
|
|
Another place :keyword:`pass` can be used is as a place-holder for a function or
|
|
|
|
conditional body when you are working on new code, allowing you to keep
|
|
|
|
thinking at a more abstract level. However, as :keyword:`pass` is silently
|
|
|
|
ignored, a better choice may be to raise a :exc:`NotImplementedError`
|
|
|
|
exception::
|
|
|
|
|
|
|
|
>>> def initlog(*args):
|
|
|
|
... raise NotImplementedError # Open logfile if not already open
|
|
|
|
... if not logfp:
|
|
|
|
... raise NotImplementedError # Set up dummy log back-end
|
|
|
|
... raise NotImplementedError('Call log initialization handler')
|
|
|
|
...
|
|
|
|
|
|
|
|
If :keyword:`pass` were used here and you later ran tests, they may fail
|
|
|
|
without indicating why. Using :exc:`NotImplementedError` causes this code
|
|
|
|
to raise an exception, telling you exactly where the incomplete code
|
|
|
|
is. Note the two calling styles of the exceptions above.
|
|
|
|
The first style, with no message but with an accompanying comment,
|
|
|
|
lets you easily leave the comment when you remove the exception,
|
|
|
|
which ideally would be a good description for
|
|
|
|
the block of code the exception is a placeholder for. However, the
|
|
|
|
third example, providing a message for the exception, will produce
|
|
|
|
a more useful traceback.
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
.. _tut-functions:
|
|
|
|
|
|
|
|
Defining Functions
|
|
|
|
==================
|
|
|
|
|
|
|
|
We can create a function that writes the Fibonacci series to an arbitrary
|
|
|
|
boundary::
|
|
|
|
|
|
|
|
>>> def fib(n): # write Fibonacci series up to n
|
|
|
|
... """Print a 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
|
|
|
|
|
|
|
|
.. index::
|
|
|
|
single: documentation strings
|
|
|
|
single: docstrings
|
|
|
|
single: strings, documentation
|
|
|
|
|
|
|
|
The keyword :keyword:`def` introduces a function *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 start at the next line, and
|
2008-09-13 14:18:11 -03:00
|
|
|
must be indented.
|
2007-08-15 11:28:01 -03:00
|
|
|
|
2008-09-13 14:18:11 -03:00
|
|
|
The first statement of the function body can optionally be a string literal;
|
|
|
|
this string literal is the function's documentation string, or :dfn:`docstring`.
|
|
|
|
(More about docstrings can be found in the section :ref:`tut-docstrings`.)
|
2007-08-15 11:28:01 -03:00
|
|
|
There are tools which use docstrings to automatically produce online or printed
|
|
|
|
documentation, or to let the user interactively browse through code; it's good
|
2008-09-13 14:18:11 -03:00
|
|
|
practice to include docstrings in code that you write, so make a habit of it.
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
The *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
|
2008-01-21 12:51:51 -04:00
|
|
|
first look in the local symbol table, then in the local symbol tables of
|
|
|
|
enclosing functions, then in the global symbol table, and finally in the table
|
|
|
|
of built-in names. Thus, global variables cannot be directly assigned a value
|
|
|
|
within a function (unless named in a :keyword:`global` statement), although they
|
|
|
|
may be referenced.
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
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 *call by value* (where the *value* is always an object *reference*,
|
|
|
|
not the value of the object). [#]_ 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::
|
|
|
|
|
|
|
|
>>> fib
|
|
|
|
<function fib at 10042ed0>
|
|
|
|
>>> f = fib
|
|
|
|
>>> f(100)
|
|
|
|
1 1 2 3 5 8 13 21 34 55 89
|
|
|
|
|
2008-09-13 14:18:11 -03:00
|
|
|
Coming from other languages, you might object that ``fib`` is not a function but
|
|
|
|
a procedure since it doesn't return a value. In fact, even functions without a
|
|
|
|
:keyword:`return` statement do return a value, albeit a rather boring one. This
|
|
|
|
value is called ``None`` (it's a built-in name). Writing the value ``None`` is
|
|
|
|
normally suppressed by the interpreter if it would be the only value written.
|
|
|
|
You can see it if you really want to using :keyword:`print`::
|
2007-08-15 11:28:01 -03:00
|
|
|
|
2007-10-30 14:57:12 -03:00
|
|
|
>>> fib(0)
|
2007-08-15 11:28:01 -03:00
|
|
|
>>> print fib(0)
|
|
|
|
None
|
|
|
|
|
|
|
|
It is simple to write a function that returns a list of the numbers of the
|
|
|
|
Fibonacci series, instead of printing it::
|
|
|
|
|
|
|
|
>>> def fib2(n): # return Fibonacci series up to n
|
|
|
|
... """Return a list containing the 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]
|
|
|
|
|
|
|
|
This example, as usual, demonstrates some new Python features:
|
|
|
|
|
|
|
|
* The :keyword:`return` statement returns with a value from a function.
|
|
|
|
:keyword:`return` without an expression argument returns ``None``. Falling off
|
2008-09-13 14:18:11 -03:00
|
|
|
the end of a function also returns ``None``.
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
* The statement ``result.append(b)`` calls a *method* of the list object
|
|
|
|
``result``. A method is a function that 'belongs' to an object and is named
|
|
|
|
``obj.methodname``, where ``obj`` is some object (this may be an expression),
|
|
|
|
and ``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 *classes*, as discussed later in this tutorial.)
|
|
|
|
The method :meth:`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
|
|
|
|
``result = result + [b]``, but more efficient.
|
|
|
|
|
|
|
|
|
|
|
|
.. _tut-defining:
|
|
|
|
|
|
|
|
More on Defining Functions
|
|
|
|
==========================
|
|
|
|
|
|
|
|
It is also possible to define functions with a variable number of arguments.
|
|
|
|
There are three forms, which can be combined.
|
|
|
|
|
|
|
|
|
|
|
|
.. _tut-defaultargs:
|
|
|
|
|
|
|
|
Default Argument Values
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
The most useful form is to specify a default value for one or more arguments.
|
|
|
|
This creates a function that can be called with fewer arguments than it is
|
|
|
|
defined to allow. For example::
|
|
|
|
|
|
|
|
def ask_ok(prompt, retries=4, complaint='Yes or no, please!'):
|
|
|
|
while True:
|
|
|
|
ok = raw_input(prompt)
|
|
|
|
if ok in ('y', 'ye', 'yes'): return True
|
|
|
|
if ok in ('n', 'no', 'nop', 'nope'): return False
|
|
|
|
retries = retries - 1
|
|
|
|
if retries < 0: raise IOError, 'refusenik user'
|
|
|
|
print complaint
|
|
|
|
|
|
|
|
This function can be called either like this: ``ask_ok('Do you really want to
|
|
|
|
quit?')`` or like this: ``ask_ok('OK to overwrite the file?', 2)``.
|
|
|
|
|
|
|
|
This example also introduces the :keyword:`in` keyword. This tests whether or
|
|
|
|
not a sequence contains a certain value.
|
|
|
|
|
|
|
|
The default values are evaluated at the point of function definition in the
|
|
|
|
*defining* scope, so that ::
|
|
|
|
|
|
|
|
i = 5
|
|
|
|
|
|
|
|
def f(arg=i):
|
|
|
|
print arg
|
|
|
|
|
|
|
|
i = 6
|
|
|
|
f()
|
|
|
|
|
|
|
|
will print ``5``.
|
|
|
|
|
|
|
|
**Important warning:** The default value is evaluated only once. This makes a
|
|
|
|
difference when the default is a mutable object such as a list, dictionary, or
|
|
|
|
instances of most classes. For example, the following function accumulates the
|
|
|
|
arguments passed to it on subsequent calls::
|
|
|
|
|
|
|
|
def f(a, L=[]):
|
|
|
|
L.append(a)
|
|
|
|
return L
|
|
|
|
|
|
|
|
print f(1)
|
|
|
|
print f(2)
|
|
|
|
print f(3)
|
|
|
|
|
|
|
|
This will print ::
|
|
|
|
|
|
|
|
[1]
|
|
|
|
[1, 2]
|
|
|
|
[1, 2, 3]
|
|
|
|
|
|
|
|
If you don't want the default to be shared between subsequent calls, you can
|
|
|
|
write the function like this instead::
|
|
|
|
|
|
|
|
def f(a, L=None):
|
|
|
|
if L is None:
|
|
|
|
L = []
|
|
|
|
L.append(a)
|
|
|
|
return L
|
|
|
|
|
|
|
|
|
|
|
|
.. _tut-keywordargs:
|
|
|
|
|
|
|
|
Keyword Arguments
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
Functions can also be called using keyword arguments of the form ``keyword =
|
|
|
|
value``. For instance, the following function::
|
|
|
|
|
|
|
|
def parrot(voltage, state='a stiff', action='voom', type='Norwegian Blue'):
|
|
|
|
print "-- This parrot wouldn't", action,
|
|
|
|
print "if you put", voltage, "volts through it."
|
|
|
|
print "-- Lovely plumage, the", type
|
|
|
|
print "-- It's", state, "!"
|
|
|
|
|
|
|
|
could be called in any of the following ways::
|
|
|
|
|
|
|
|
parrot(1000)
|
|
|
|
parrot(action = 'VOOOOOM', voltage = 1000000)
|
|
|
|
parrot('a thousand', state = 'pushing up the daisies')
|
|
|
|
parrot('a million', 'bereft of life', 'jump')
|
|
|
|
|
|
|
|
but the following calls would all be invalid::
|
|
|
|
|
|
|
|
parrot() # required argument missing
|
|
|
|
parrot(voltage=5.0, 'dead') # non-keyword argument following keyword
|
|
|
|
parrot(110, voltage=220) # duplicate value for argument
|
|
|
|
parrot(actor='John Cleese') # unknown keyword
|
|
|
|
|
|
|
|
In general, an argument list must have any positional arguments followed by any
|
|
|
|
keyword arguments, where the keywords must be chosen from the formal parameter
|
|
|
|
names. It's not important whether a formal parameter has a default value or
|
|
|
|
not. No argument may receive a value more than once --- formal parameter names
|
|
|
|
corresponding to positional arguments cannot be used as keywords in the same
|
|
|
|
calls. Here's an example that fails due to this restriction::
|
|
|
|
|
|
|
|
>>> def function(a):
|
|
|
|
... pass
|
|
|
|
...
|
|
|
|
>>> function(0, a=0)
|
|
|
|
Traceback (most recent call last):
|
|
|
|
File "<stdin>", line 1, in ?
|
|
|
|
TypeError: function() got multiple values for keyword argument 'a'
|
|
|
|
|
|
|
|
When a final formal parameter of the form ``**name`` is present, it receives a
|
|
|
|
dictionary (see :ref:`typesmapping`) containing all keyword arguments except for
|
|
|
|
those corresponding to a formal parameter. This may be combined with a formal
|
|
|
|
parameter of the form ``*name`` (described in the next subsection) which
|
|
|
|
receives a tuple containing the positional arguments beyond the formal parameter
|
|
|
|
list. (``*name`` must occur before ``**name``.) For example, if we define a
|
|
|
|
function like this::
|
|
|
|
|
|
|
|
def cheeseshop(kind, *arguments, **keywords):
|
2008-09-13 14:18:11 -03:00
|
|
|
print "-- Do you have any", kind, "?"
|
2007-08-15 11:28:01 -03:00
|
|
|
print "-- I'm sorry, we're all out of", kind
|
|
|
|
for arg in arguments: print arg
|
2008-09-13 14:18:11 -03:00
|
|
|
print "-" * 40
|
2007-08-15 11:28:01 -03:00
|
|
|
keys = keywords.keys()
|
|
|
|
keys.sort()
|
2008-09-13 14:18:11 -03:00
|
|
|
for kw in keys: print kw, ":", keywords[kw]
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
It could be called like this::
|
|
|
|
|
2008-09-13 14:18:11 -03:00
|
|
|
cheeseshop("Limburger", "It's very runny, sir.",
|
2007-08-15 11:28:01 -03:00
|
|
|
"It's really very, VERY runny, sir.",
|
|
|
|
shopkeeper='Michael Palin',
|
2008-09-13 14:18:11 -03:00
|
|
|
client="John Cleese",
|
|
|
|
sketch="Cheese Shop Sketch")
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
and of course it would print::
|
|
|
|
|
|
|
|
-- Do you have any Limburger ?
|
|
|
|
-- I'm sorry, we're all out of Limburger
|
|
|
|
It's very runny, sir.
|
|
|
|
It's really very, VERY runny, sir.
|
|
|
|
----------------------------------------
|
|
|
|
client : John Cleese
|
|
|
|
shopkeeper : Michael Palin
|
|
|
|
sketch : Cheese Shop Sketch
|
|
|
|
|
|
|
|
Note that the :meth:`sort` method of the list of keyword argument names is
|
|
|
|
called before printing the contents of the ``keywords`` dictionary; if this is
|
|
|
|
not done, the order in which the arguments are printed is undefined.
|
|
|
|
|
|
|
|
|
|
|
|
.. _tut-arbitraryargs:
|
|
|
|
|
|
|
|
Arbitrary Argument Lists
|
|
|
|
------------------------
|
|
|
|
|
2008-04-15 10:10:07 -03:00
|
|
|
.. index::
|
|
|
|
statement: *
|
|
|
|
|
2007-08-15 11:28:01 -03:00
|
|
|
Finally, the least frequently used option is to specify that a function can be
|
|
|
|
called with an arbitrary number of arguments. These arguments will be wrapped
|
2008-09-13 14:18:11 -03:00
|
|
|
up in a tuple (see :ref:`tut-tuples`). Before the variable number of arguments,
|
|
|
|
zero or more normal arguments may occur. ::
|
2007-08-15 11:28:01 -03:00
|
|
|
|
2008-05-28 08:51:41 -03:00
|
|
|
def write_multiple_items(file, separator, *args):
|
|
|
|
file.write(separator.join(args))
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
|
|
|
|
.. _tut-unpacking-arguments:
|
|
|
|
|
|
|
|
Unpacking Argument Lists
|
|
|
|
------------------------
|
|
|
|
|
|
|
|
The reverse situation occurs when the arguments are already in a list or tuple
|
|
|
|
but need to be unpacked for a function call requiring separate positional
|
|
|
|
arguments. For instance, the built-in :func:`range` function expects separate
|
|
|
|
*start* and *stop* arguments. If they are not available separately, write the
|
|
|
|
function call with the ``*``\ -operator to unpack the arguments out of a list
|
|
|
|
or tuple::
|
|
|
|
|
|
|
|
>>> range(3, 6) # normal call with separate arguments
|
|
|
|
[3, 4, 5]
|
|
|
|
>>> args = [3, 6]
|
|
|
|
>>> range(*args) # call with arguments unpacked from a list
|
|
|
|
[3, 4, 5]
|
|
|
|
|
2008-04-15 10:10:07 -03:00
|
|
|
.. index::
|
|
|
|
statement: **
|
|
|
|
|
2007-08-15 11:28:01 -03:00
|
|
|
In the same fashion, dictionaries can deliver keyword arguments with the ``**``\
|
|
|
|
-operator::
|
|
|
|
|
|
|
|
>>> def parrot(voltage, state='a stiff', action='voom'):
|
|
|
|
... print "-- This parrot wouldn't", action,
|
|
|
|
... print "if you put", voltage, "volts through it.",
|
|
|
|
... print "E's", state, "!"
|
|
|
|
...
|
|
|
|
>>> d = {"voltage": "four million", "state": "bleedin' demised", "action": "VOOM"}
|
|
|
|
>>> parrot(**d)
|
|
|
|
-- This parrot wouldn't VOOM if you put four million volts through it. E's bleedin' demised !
|
|
|
|
|
|
|
|
|
|
|
|
.. _tut-lambda:
|
|
|
|
|
|
|
|
Lambda Forms
|
|
|
|
------------
|
|
|
|
|
|
|
|
By popular demand, a few features commonly found in functional programming
|
|
|
|
languages like Lisp have been added to Python. With the :keyword:`lambda`
|
|
|
|
keyword, small anonymous functions can be created. Here's a function that
|
|
|
|
returns the sum of its two arguments: ``lambda a, b: a+b``. Lambda forms can be
|
|
|
|
used wherever function objects are required. They are syntactically restricted
|
|
|
|
to a single expression. Semantically, they are just syntactic sugar for a
|
|
|
|
normal function definition. Like nested function definitions, lambda forms can
|
|
|
|
reference variables from the containing scope::
|
|
|
|
|
|
|
|
>>> def make_incrementor(n):
|
|
|
|
... return lambda x: x + n
|
|
|
|
...
|
|
|
|
>>> f = make_incrementor(42)
|
|
|
|
>>> f(0)
|
|
|
|
42
|
|
|
|
>>> f(1)
|
|
|
|
43
|
|
|
|
|
|
|
|
|
|
|
|
.. _tut-docstrings:
|
|
|
|
|
|
|
|
Documentation Strings
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
.. index::
|
|
|
|
single: docstrings
|
|
|
|
single: documentation strings
|
|
|
|
single: strings, documentation
|
|
|
|
|
|
|
|
There are emerging conventions about the content and formatting of documentation
|
|
|
|
strings.
|
|
|
|
|
|
|
|
The first line should always be a short, concise summary of the object's
|
|
|
|
purpose. For brevity, it should not explicitly state the object's name or type,
|
|
|
|
since these are available by other means (except if the name happens to be a
|
|
|
|
verb describing a function's operation). This line should begin with a capital
|
|
|
|
letter and end with a period.
|
|
|
|
|
|
|
|
If there are more lines in the documentation string, the second line should be
|
|
|
|
blank, visually separating the summary from the rest of the description. The
|
|
|
|
following lines should be one or more paragraphs describing the object's calling
|
|
|
|
conventions, its side effects, etc.
|
|
|
|
|
|
|
|
The Python parser does not strip indentation from multi-line string literals in
|
|
|
|
Python, so tools that process documentation have to strip indentation if
|
|
|
|
desired. This is done using the following convention. The first non-blank line
|
|
|
|
*after* the first line of the string determines the amount of indentation for
|
|
|
|
the entire documentation string. (We can't use the first line since it is
|
|
|
|
generally adjacent to the string's opening quotes so its indentation is not
|
|
|
|
apparent in the string literal.) Whitespace "equivalent" to this indentation is
|
|
|
|
then stripped from the start of all lines of the string. Lines that are
|
|
|
|
indented less should not occur, but if they occur all their leading whitespace
|
|
|
|
should be stripped. Equivalence of whitespace should be tested after expansion
|
|
|
|
of tabs (to 8 spaces, normally).
|
|
|
|
|
|
|
|
Here is an example of a multi-line docstring::
|
|
|
|
|
|
|
|
>>> def my_function():
|
|
|
|
... """Do nothing, but document it.
|
|
|
|
...
|
|
|
|
... No, really, it doesn't do anything.
|
|
|
|
... """
|
|
|
|
... pass
|
|
|
|
...
|
|
|
|
>>> print my_function.__doc__
|
|
|
|
Do nothing, but document it.
|
|
|
|
|
|
|
|
No, really, it doesn't do anything.
|
|
|
|
|
|
|
|
|
2008-01-06 18:05:40 -04:00
|
|
|
.. _tut-codingstyle:
|
|
|
|
|
|
|
|
Intermezzo: Coding Style
|
|
|
|
========================
|
|
|
|
|
|
|
|
.. sectionauthor:: Georg Brandl <georg@python.org>
|
|
|
|
.. index:: pair: coding; style
|
|
|
|
|
|
|
|
Now that you are about to write longer, more complex pieces of Python, it is a
|
|
|
|
good time to talk about *coding style*. Most languages can be written (or more
|
|
|
|
concise, *formatted*) in different styles; some are more readable than others.
|
|
|
|
Making it easy for others to read your code is always a good idea, and adopting
|
|
|
|
a nice coding style helps tremendously for that.
|
|
|
|
|
2008-04-15 10:10:41 -03:00
|
|
|
For Python, :pep:`8` has emerged as the style guide that most projects adhere to;
|
2008-01-06 18:05:40 -04:00
|
|
|
it promotes a very readable and eye-pleasing coding style. Every Python
|
|
|
|
developer should read it at some point; here are the most important points
|
|
|
|
extracted for you:
|
|
|
|
|
|
|
|
* Use 4-space indentation, and no tabs.
|
|
|
|
|
|
|
|
4 spaces are a good compromise between small indentation (allows greater
|
|
|
|
nesting depth) and large indentation (easier to read). Tabs introduce
|
|
|
|
confusion, and are best left out.
|
|
|
|
|
|
|
|
* Wrap lines so that they don't exceed 79 characters.
|
|
|
|
|
|
|
|
This helps users with small displays and makes it possible to have several
|
|
|
|
code files side-by-side on larger displays.
|
|
|
|
|
|
|
|
* Use blank lines to separate functions and classes, and larger blocks of
|
|
|
|
code inside functions.
|
|
|
|
|
|
|
|
* When possible, put comments on a line of their own.
|
|
|
|
|
|
|
|
* Use docstrings.
|
|
|
|
|
|
|
|
* Use spaces around operators and after commas, but not directly inside
|
|
|
|
bracketing constructs: ``a = f(1, 2) + g(3, 4)``.
|
|
|
|
|
|
|
|
* Name your classes and functions consistently; the convention is to use
|
|
|
|
``CamelCase`` for classes and ``lower_case_with_underscores`` for functions
|
2008-09-13 14:18:11 -03:00
|
|
|
and methods. Always use ``self`` as the name for the first method argument
|
|
|
|
(see :ref:`tut-firstclasses` for more on classes and methods).
|
2008-01-06 18:05:40 -04:00
|
|
|
|
|
|
|
* Don't use fancy encodings if your code is meant to be used in international
|
|
|
|
environments. Plain ASCII works best in any case.
|
|
|
|
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
.. rubric:: Footnotes
|
|
|
|
|
2008-01-06 18:05:40 -04:00
|
|
|
.. [#] Actually, *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 (items inserted into a list).
|
2007-08-15 11:28:01 -03:00
|
|
|
|