mirror of
https://github.com/python/cpython.git
synced 2024-12-01 11:15:56 +01:00
c62efa87f6
svn+ssh://svn.python.org/python/branches/py3k ................ r82301 | benjamin.peterson | 2010-06-28 00:32:30 +0200 (Mo, 28 Jun 2010) | 303 lines Merged revisions 80605-80609,80642-80646,80651-80652,80674,80684-80686,80748,80852,80854,80870,80872-80873,80907,80915-80916,80951-80952,80976-80977,80985,81038-81040,81042,81053,81070,81104-81105,81114,81125,81245,81285,81402,81463,81516,81562-81563,81567,81593,81635,81680-81681,81684,81801,81888,81931-81933,81939-81942,81963,81984,81991,82120,82188,82264-82267 via svnmerge from svn+ssh://pythondev@svn.python.org/python/trunk ........ r80605 | andrew.kuchling | 2010-04-28 19:22:16 -0500 (Wed, 28 Apr 2010) | 1 line Add various items ........ r80606 | andrew.kuchling | 2010-04-28 20:44:30 -0500 (Wed, 28 Apr 2010) | 6 lines Fix doubled 'the'. Markup fixes to use :exc:, :option: in a few places. (Glitch: unittest.main's -c ends up a link to the Python interpreter's -c option. Should we skip using :option: for that switch, or disable the auto-linking somehow?) ........ r80607 | andrew.kuchling | 2010-04-28 20:45:41 -0500 (Wed, 28 Apr 2010) | 1 line Add various unittest items ........ r80608 | benjamin.peterson | 2010-04-28 22:18:05 -0500 (Wed, 28 Apr 2010) | 1 line update pypy description ........ r80609 | benjamin.peterson | 2010-04-28 22:30:59 -0500 (Wed, 28 Apr 2010) | 1 line update pypy url ........ r80642 | andrew.kuchling | 2010-04-29 19:49:09 -0500 (Thu, 29 Apr 2010) | 1 line Always add space after RFC; reword paragraph ........ r80643 | andrew.kuchling | 2010-04-29 19:52:31 -0500 (Thu, 29 Apr 2010) | 6 lines Reword paragraph to make its meaning clearer. Antoine Pitrou: is my version of the paragraph still correct? R. David Murray: is this more understandable than the previous version? ........ r80644 | andrew.kuchling | 2010-04-29 20:02:15 -0500 (Thu, 29 Apr 2010) | 1 line Fix typos ........ r80645 | andrew.kuchling | 2010-04-29 20:32:47 -0500 (Thu, 29 Apr 2010) | 1 line Markup fix; clarify by adding 'in that order' ........ r80646 | andrew.kuchling | 2010-04-29 20:33:40 -0500 (Thu, 29 Apr 2010) | 1 line Add various items; rearrange unittest section a bit ........ r80651 | andrew.kuchling | 2010-04-30 08:46:55 -0500 (Fri, 30 Apr 2010) | 1 line Minor grammar re-wording ........ r80652 | andrew.kuchling | 2010-04-30 08:47:34 -0500 (Fri, 30 Apr 2010) | 1 line Add item ........ r80674 | andrew.kuchling | 2010-04-30 20:19:16 -0500 (Fri, 30 Apr 2010) | 1 line Add various items ........ r80684 | andrew.kuchling | 2010-05-01 07:05:52 -0500 (Sat, 01 May 2010) | 1 line Minor grammar fix ........ r80685 | andrew.kuchling | 2010-05-01 07:06:51 -0500 (Sat, 01 May 2010) | 1 line Describe memoryview ........ r80686 | antoine.pitrou | 2010-05-01 07:16:39 -0500 (Sat, 01 May 2010) | 4 lines Fix attribution. Travis didn't do much and he did a bad work. (yes, this is a sensitive subject, sorry) ........ r80748 | andrew.kuchling | 2010-05-03 20:24:22 -0500 (Mon, 03 May 2010) | 1 line Add some more items; the urlparse change is added twice ........ r80852 | andrew.kuchling | 2010-05-05 20:09:47 -0500 (Wed, 05 May 2010) | 1 line Reword paragraph; fix filename, which should be pyconfig.h ........ r80854 | andrew.kuchling | 2010-05-05 20:10:56 -0500 (Wed, 05 May 2010) | 1 line Add various items ........ r80870 | andrew.kuchling | 2010-05-06 09:14:09 -0500 (Thu, 06 May 2010) | 1 line Describe ElementTree 1.3; rearrange new-module sections; describe dict views as sets; small edits and items ........ r80872 | andrew.kuchling | 2010-05-06 12:21:59 -0500 (Thu, 06 May 2010) | 1 line Add 2 items; record ideas for two initial sections; clarify wording ........ r80873 | andrew.kuchling | 2010-05-06 12:27:57 -0500 (Thu, 06 May 2010) | 1 line Change section title; point to unittest2 ........ r80907 | andrew.kuchling | 2010-05-06 20:45:14 -0500 (Thu, 06 May 2010) | 1 line Add a new section on the development plan; add an item ........ r80915 | antoine.pitrou | 2010-05-07 05:15:51 -0500 (Fri, 07 May 2010) | 3 lines Fix some markup and a class name. Also, wrap a long line. ........ r80916 | andrew.kuchling | 2010-05-07 06:30:47 -0500 (Fri, 07 May 2010) | 1 line Re-word text ........ r80951 | andrew.kuchling | 2010-05-07 20:15:26 -0500 (Fri, 07 May 2010) | 1 line Add two items ........ r80952 | andrew.kuchling | 2010-05-07 20:35:55 -0500 (Fri, 07 May 2010) | 1 line Get accents correct ........ r80976 | andrew.kuchling | 2010-05-08 08:28:03 -0500 (Sat, 08 May 2010) | 1 line Add logging.dictConfig example; give up on writing a Ttk example ........ r80977 | andrew.kuchling | 2010-05-08 08:29:46 -0500 (Sat, 08 May 2010) | 1 line Markup fixes ........ r80985 | andrew.kuchling | 2010-05-08 10:39:46 -0500 (Sat, 08 May 2010) | 7 lines Write summary of the 2.7 release; rewrite the future section some more; mention PYTHONWARNINGS env. var; tweak some examples for readability. And with this commit, the "What's New" is done... except for a complete read-through to polish the text, and fixing any reported errors, but those tasks can easily wait until after beta2. ........ r81038 | benjamin.peterson | 2010-05-09 16:09:40 -0500 (Sun, 09 May 2010) | 1 line finish clause ........ r81039 | andrew.kuchling | 2010-05-10 09:18:27 -0500 (Mon, 10 May 2010) | 1 line Markup fix; re-word a sentence ........ r81040 | andrew.kuchling | 2010-05-10 09:20:12 -0500 (Mon, 10 May 2010) | 1 line Use title case ........ r81042 | andrew.kuchling | 2010-05-10 10:03:35 -0500 (Mon, 10 May 2010) | 1 line Link to unittest2 article ........ r81053 | florent.xicluna | 2010-05-10 14:59:22 -0500 (Mon, 10 May 2010) | 2 lines Add a link on maketrans(). ........ r81070 | andrew.kuchling | 2010-05-10 18:13:41 -0500 (Mon, 10 May 2010) | 1 line Fix typo ........ r81104 | andrew.kuchling | 2010-05-11 19:38:44 -0500 (Tue, 11 May 2010) | 1 line Revision pass: lots of edits, typo fixes, rearrangements ........ r81105 | andrew.kuchling | 2010-05-11 19:40:47 -0500 (Tue, 11 May 2010) | 1 line Let's call this done ........ r81114 | andrew.kuchling | 2010-05-12 08:56:07 -0500 (Wed, 12 May 2010) | 1 line Grammar fix ........ r81125 | andrew.kuchling | 2010-05-12 13:56:48 -0500 (Wed, 12 May 2010) | 1 line #8696: add documentation for logging.config.dictConfig (PEP 391) ........ r81245 | andrew.kuchling | 2010-05-16 18:31:16 -0500 (Sun, 16 May 2010) | 1 line Add cross-reference to later section ........ r81285 | vinay.sajip | 2010-05-18 03:16:27 -0500 (Tue, 18 May 2010) | 1 line Fixed minor typo in ReST markup. ........ r81402 | vinay.sajip | 2010-05-21 12:41:34 -0500 (Fri, 21 May 2010) | 1 line Updated logging documentation with more dictConfig information. ........ r81463 | georg.brandl | 2010-05-22 03:17:23 -0500 (Sat, 22 May 2010) | 1 line #8785: less confusing description of regex.find*. ........ r81516 | andrew.kuchling | 2010-05-25 08:34:08 -0500 (Tue, 25 May 2010) | 1 line Add three items ........ r81562 | andrew.kuchling | 2010-05-27 08:22:53 -0500 (Thu, 27 May 2010) | 1 line Rewrite wxWidgets section ........ r81563 | andrew.kuchling | 2010-05-27 08:30:09 -0500 (Thu, 27 May 2010) | 1 line Remove top-level 'General Questions' section, pushing up the questions it contains ........ r81567 | andrew.kuchling | 2010-05-27 16:29:59 -0500 (Thu, 27 May 2010) | 1 line Add item ........ r81593 | georg.brandl | 2010-05-29 03:46:18 -0500 (Sat, 29 May 2010) | 1 line #8616: add new turtle demo "nim". ........ r81635 | georg.brandl | 2010-06-01 02:25:23 -0500 (Tue, 01 Jun 2010) | 1 line Put docs for RegexObject.search() before RegexObject.match() to mirror re.search() and re.match() order. ........ r81680 | vinay.sajip | 2010-06-03 17:34:42 -0500 (Thu, 03 Jun 2010) | 1 line Issue #8890: Documentation changed to avoid reference to temporary files. ........ r81681 | sean.reifschneider | 2010-06-03 20:51:26 -0500 (Thu, 03 Jun 2010) | 2 lines Issue8810: Clearing up docstring for tzinfo.utcoffset. ........ r81684 | vinay.sajip | 2010-06-04 08:41:02 -0500 (Fri, 04 Jun 2010) | 1 line Issue #8890: Documentation changed to avoid reference to temporary files - other cases covered. ........ r81801 | andrew.kuchling | 2010-06-07 08:38:40 -0500 (Mon, 07 Jun 2010) | 1 line #8875: Remove duplicated paragraph ........ r81888 | andrew.kuchling | 2010-06-10 20:54:58 -0500 (Thu, 10 Jun 2010) | 1 line Add a few more items ........ r81931 | georg.brandl | 2010-06-12 01:26:54 -0500 (Sat, 12 Jun 2010) | 1 line Fix punctuation. ........ r81932 | georg.brandl | 2010-06-12 01:28:58 -0500 (Sat, 12 Jun 2010) | 1 line Document that an existing directory raises in mkdir(). ........ r81933 | georg.brandl | 2010-06-12 01:45:33 -0500 (Sat, 12 Jun 2010) | 1 line Update version in README. ........ r81939 | georg.brandl | 2010-06-12 04:45:01 -0500 (Sat, 12 Jun 2010) | 1 line Use newer toctree syntax. ........ r81940 | georg.brandl | 2010-06-12 04:45:28 -0500 (Sat, 12 Jun 2010) | 1 line Add document on how to build. ........ r81941 | georg.brandl | 2010-06-12 04:45:58 -0500 (Sat, 12 Jun 2010) | 1 line Fix gratuitous indentation. ........ r81942 | georg.brandl | 2010-06-12 04:46:03 -0500 (Sat, 12 Jun 2010) | 1 line Update README. ........ r81963 | andrew.kuchling | 2010-06-12 15:00:55 -0500 (Sat, 12 Jun 2010) | 1 line Grammar fix ........ r81984 | georg.brandl | 2010-06-14 10:58:39 -0500 (Mon, 14 Jun 2010) | 1 line #8993: fix reference. ........ r81991 | andrew.kuchling | 2010-06-14 19:38:58 -0500 (Mon, 14 Jun 2010) | 1 line Add another bunch of items ........ r82120 | andrew.kuchling | 2010-06-20 16:45:45 -0500 (Sun, 20 Jun 2010) | 1 line Note that Python 3.x isn't covered; add forward ref. for UTF-8; note error in 2.5 and up ........ r82188 | benjamin.peterson | 2010-06-23 19:02:46 -0500 (Wed, 23 Jun 2010) | 1 line remove reverted changed ........ r82264 | georg.brandl | 2010-06-27 05:47:47 -0500 (Sun, 27 Jun 2010) | 1 line Confusing punctuation. ........ r82265 | georg.brandl | 2010-06-27 05:49:23 -0500 (Sun, 27 Jun 2010) | 1 line Use designated syntax for optional grammar element. ........ r82266 | georg.brandl | 2010-06-27 05:51:44 -0500 (Sun, 27 Jun 2010) | 1 line Fix URL. ........ r82267 | georg.brandl | 2010-06-27 05:55:38 -0500 (Sun, 27 Jun 2010) | 1 line Two typos. ........ ................
1359 lines
49 KiB
ReStructuredText
1359 lines
49 KiB
ReStructuredText
********************************
|
|
Functional Programming HOWTO
|
|
********************************
|
|
|
|
:Author: A. M. Kuchling
|
|
:Release: 0.31
|
|
|
|
In this document, we'll take a tour of Python's features suitable for
|
|
implementing programs in a functional style. After an introduction to the
|
|
concepts of functional programming, we'll look at language features such as
|
|
:term:`iterator`\s and :term:`generator`\s and relevant library modules such as
|
|
:mod:`itertools` and :mod:`functools`.
|
|
|
|
|
|
Introduction
|
|
============
|
|
|
|
This section explains the basic concept of functional programming; if you're
|
|
just interested in learning about Python language features, skip to the next
|
|
section.
|
|
|
|
Programming languages support decomposing problems in several different ways:
|
|
|
|
* Most programming languages are **procedural**: programs are lists of
|
|
instructions that tell the computer what to do with the program's input. C,
|
|
Pascal, and even Unix shells are procedural languages.
|
|
|
|
* In **declarative** languages, you write a specification that describes the
|
|
problem to be solved, and the language implementation figures out how to
|
|
perform the computation efficiently. SQL is the declarative language you're
|
|
most likely to be familiar with; a SQL query describes the data set you want
|
|
to retrieve, and the SQL engine decides whether to scan tables or use indexes,
|
|
which subclauses should be performed first, etc.
|
|
|
|
* **Object-oriented** programs manipulate collections of objects. Objects have
|
|
internal state and support methods that query or modify this internal state in
|
|
some way. Smalltalk and Java are object-oriented languages. C++ and Python
|
|
are languages that support object-oriented programming, but don't force the
|
|
use of object-oriented features.
|
|
|
|
* **Functional** programming decomposes a problem into a set of functions.
|
|
Ideally, functions only take inputs and produce outputs, and don't have any
|
|
internal state that affects the output produced for a given input. Well-known
|
|
functional languages include the ML family (Standard ML, OCaml, and other
|
|
variants) and Haskell.
|
|
|
|
The designers of some computer languages choose to emphasize one
|
|
particular approach to programming. This often makes it difficult to
|
|
write programs that use a different approach. Other languages are
|
|
multi-paradigm languages that support several different approaches.
|
|
Lisp, C++, and Python are multi-paradigm; you can write programs or
|
|
libraries that are largely procedural, object-oriented, or functional
|
|
in all of these languages. In a large program, different sections
|
|
might be written using different approaches; the GUI might be
|
|
object-oriented while the processing logic is procedural or
|
|
functional, for example.
|
|
|
|
In a functional program, input flows through a set of functions. Each function
|
|
operates on its input and produces some output. Functional style discourages
|
|
functions with side effects that modify internal state or make other changes
|
|
that aren't visible in the function's return value. Functions that have no side
|
|
effects at all are called **purely functional**. Avoiding side effects means
|
|
not using data structures that get updated as a program runs; every function's
|
|
output must only depend on its input.
|
|
|
|
Some languages are very strict about purity and don't even have assignment
|
|
statements such as ``a=3`` or ``c = a + b``, but it's difficult to avoid all
|
|
side effects. Printing to the screen or writing to a disk file are side
|
|
effects, for example. For example, in Python a call to the :func:`print` or
|
|
:func:`time.sleep` function both return no useful value; they're only called for
|
|
their side effects of sending some text to the screen or pausing execution for a
|
|
second.
|
|
|
|
Python programs written in functional style usually won't go to the extreme of
|
|
avoiding all I/O or all assignments; instead, they'll provide a
|
|
functional-appearing interface but will use non-functional features internally.
|
|
For example, the implementation of a function will still use assignments to
|
|
local variables, but won't modify global variables or have other side effects.
|
|
|
|
Functional programming can be considered the opposite of object-oriented
|
|
programming. Objects are little capsules containing some internal state along
|
|
with a collection of method calls that let you modify this state, and programs
|
|
consist of making the right set of state changes. Functional programming wants
|
|
to avoid state changes as much as possible and works with data flowing between
|
|
functions. In Python you might combine the two approaches by writing functions
|
|
that take and return instances representing objects in your application (e-mail
|
|
messages, transactions, etc.).
|
|
|
|
Functional design may seem like an odd constraint to work under. Why should you
|
|
avoid objects and side effects? There are theoretical and practical advantages
|
|
to the functional style:
|
|
|
|
* Formal provability.
|
|
* Modularity.
|
|
* Composability.
|
|
* Ease of debugging and testing.
|
|
|
|
|
|
Formal provability
|
|
------------------
|
|
|
|
A theoretical benefit is that it's easier to construct a mathematical proof that
|
|
a functional program is correct.
|
|
|
|
For a long time researchers have been interested in finding ways to
|
|
mathematically prove programs correct. This is different from testing a program
|
|
on numerous inputs and concluding that its output is usually correct, or reading
|
|
a program's source code and concluding that the code looks right; the goal is
|
|
instead a rigorous proof that a program produces the right result for all
|
|
possible inputs.
|
|
|
|
The technique used to prove programs correct is to write down **invariants**,
|
|
properties of the input data and of the program's variables that are always
|
|
true. For each line of code, you then show that if invariants X and Y are true
|
|
**before** the line is executed, the slightly different invariants X' and Y' are
|
|
true **after** the line is executed. This continues until you reach the end of
|
|
the program, at which point the invariants should match the desired conditions
|
|
on the program's output.
|
|
|
|
Functional programming's avoidance of assignments arose because assignments are
|
|
difficult to handle with this technique; assignments can break invariants that
|
|
were true before the assignment without producing any new invariants that can be
|
|
propagated onward.
|
|
|
|
Unfortunately, proving programs correct is largely impractical and not relevant
|
|
to Python software. Even trivial programs require proofs that are several pages
|
|
long; the proof of correctness for a moderately complicated program would be
|
|
enormous, and few or none of the programs you use daily (the Python interpreter,
|
|
your XML parser, your web browser) could be proven correct. Even if you wrote
|
|
down or generated a proof, there would then be the question of verifying the
|
|
proof; maybe there's an error in it, and you wrongly believe you've proved the
|
|
program correct.
|
|
|
|
|
|
Modularity
|
|
----------
|
|
|
|
A more practical benefit of functional programming is that it forces you to
|
|
break apart your problem into small pieces. Programs are more modular as a
|
|
result. It's easier to specify and write a small function that does one thing
|
|
than a large function that performs a complicated transformation. Small
|
|
functions are also easier to read and to check for errors.
|
|
|
|
|
|
Ease of debugging and testing
|
|
-----------------------------
|
|
|
|
Testing and debugging a functional-style program is easier.
|
|
|
|
Debugging is simplified because functions are generally small and clearly
|
|
specified. When a program doesn't work, each function is an interface point
|
|
where you can check that the data are correct. You can look at the intermediate
|
|
inputs and outputs to quickly isolate the function that's responsible for a bug.
|
|
|
|
Testing is easier because each function is a potential subject for a unit test.
|
|
Functions don't depend on system state that needs to be replicated before
|
|
running a test; instead you only have to synthesize the right input and then
|
|
check that the output matches expectations.
|
|
|
|
|
|
Composability
|
|
-------------
|
|
|
|
As you work on a functional-style program, you'll write a number of functions
|
|
with varying inputs and outputs. Some of these functions will be unavoidably
|
|
specialized to a particular application, but others will be useful in a wide
|
|
variety of programs. For example, a function that takes a directory path and
|
|
returns all the XML files in the directory, or a function that takes a filename
|
|
and returns its contents, can be applied to many different situations.
|
|
|
|
Over time you'll form a personal library of utilities. Often you'll assemble
|
|
new programs by arranging existing functions in a new configuration and writing
|
|
a few functions specialized for the current task.
|
|
|
|
|
|
Iterators
|
|
=========
|
|
|
|
I'll start by looking at a Python language feature that's an important
|
|
foundation for writing functional-style programs: iterators.
|
|
|
|
An iterator is an object representing a stream of data; this object returns the
|
|
data one element at a time. A Python iterator must support a method called
|
|
``__next__()`` that takes no arguments and always returns the next element of
|
|
the stream. If there are no more elements in the stream, ``__next__()`` must
|
|
raise the ``StopIteration`` exception. Iterators don't have to be finite,
|
|
though; it's perfectly reasonable to write an iterator that produces an infinite
|
|
stream of data.
|
|
|
|
The built-in :func:`iter` function takes an arbitrary object and tries to return
|
|
an iterator that will return the object's contents or elements, raising
|
|
:exc:`TypeError` if the object doesn't support iteration. Several of Python's
|
|
built-in data types support iteration, the most common being lists and
|
|
dictionaries. An object is called an **iterable** object if you can get an
|
|
iterator for it.
|
|
|
|
You can experiment with the iteration interface manually:
|
|
|
|
>>> L = [1,2,3]
|
|
>>> it = iter(L)
|
|
>>> it
|
|
<...iterator object at ...>
|
|
>>> it.__next__()
|
|
1
|
|
>>> next(it)
|
|
2
|
|
>>> next(it)
|
|
3
|
|
>>> next(it)
|
|
Traceback (most recent call last):
|
|
File "<stdin>", line 1, in ?
|
|
StopIteration
|
|
>>>
|
|
|
|
Python expects iterable objects in several different contexts, the most
|
|
important being the ``for`` statement. In the statement ``for X in Y``, Y must
|
|
be an iterator or some object for which ``iter()`` can create an iterator.
|
|
These two statements are equivalent::
|
|
|
|
|
|
for i in iter(obj):
|
|
print(i)
|
|
|
|
for i in obj:
|
|
print(i)
|
|
|
|
Iterators can be materialized as lists or tuples by using the :func:`list` or
|
|
:func:`tuple` constructor functions:
|
|
|
|
>>> L = [1,2,3]
|
|
>>> iterator = iter(L)
|
|
>>> t = tuple(iterator)
|
|
>>> t
|
|
(1, 2, 3)
|
|
|
|
Sequence unpacking also supports iterators: if you know an iterator will return
|
|
N elements, you can unpack them into an N-tuple:
|
|
|
|
>>> L = [1,2,3]
|
|
>>> iterator = iter(L)
|
|
>>> a,b,c = iterator
|
|
>>> a,b,c
|
|
(1, 2, 3)
|
|
|
|
Built-in functions such as :func:`max` and :func:`min` can take a single
|
|
iterator argument and will return the largest or smallest element. The ``"in"``
|
|
and ``"not in"`` operators also support iterators: ``X in iterator`` is true if
|
|
X is found in the stream returned by the iterator. You'll run into obvious
|
|
problems if the iterator is infinite; ``max()``, ``min()``, and ``"not in"``
|
|
will never return, and if the element X never appears in the stream, the
|
|
``"in"`` operator won't return either.
|
|
|
|
Note that you can only go forward in an iterator; there's no way to get the
|
|
previous element, reset the iterator, or make a copy of it. Iterator objects
|
|
can optionally provide these additional capabilities, but the iterator protocol
|
|
only specifies the ``next()`` method. Functions may therefore consume all of
|
|
the iterator's output, and if you need to do something different with the same
|
|
stream, you'll have to create a new iterator.
|
|
|
|
|
|
|
|
Data Types That Support Iterators
|
|
---------------------------------
|
|
|
|
We've already seen how lists and tuples support iterators. In fact, any Python
|
|
sequence type, such as strings, will automatically support creation of an
|
|
iterator.
|
|
|
|
Calling :func:`iter` on a dictionary returns an iterator that will loop over the
|
|
dictionary's keys:
|
|
|
|
.. not a doctest since dict ordering varies across Pythons
|
|
|
|
::
|
|
|
|
>>> m = {'Jan': 1, 'Feb': 2, 'Mar': 3, 'Apr': 4, 'May': 5, 'Jun': 6,
|
|
... 'Jul': 7, 'Aug': 8, 'Sep': 9, 'Oct': 10, 'Nov': 11, 'Dec': 12}
|
|
>>> for key in m:
|
|
... print(key, m[key])
|
|
Mar 3
|
|
Feb 2
|
|
Aug 8
|
|
Sep 9
|
|
Apr 4
|
|
Jun 6
|
|
Jul 7
|
|
Jan 1
|
|
May 5
|
|
Nov 11
|
|
Dec 12
|
|
Oct 10
|
|
|
|
Note that the order is essentially random, because it's based on the hash
|
|
ordering of the objects in the dictionary.
|
|
|
|
Applying :func:`iter` to a dictionary always loops over the keys, but
|
|
dictionaries have methods that return other iterators. If you want to iterate
|
|
over values or key/value pairs, you can explicitly call the
|
|
:meth:`values` or :meth:`items` methods to get an appropriate iterator.
|
|
|
|
The :func:`dict` constructor can accept an iterator that returns a finite stream
|
|
of ``(key, value)`` tuples:
|
|
|
|
>>> L = [('Italy', 'Rome'), ('France', 'Paris'), ('US', 'Washington DC')]
|
|
>>> dict(iter(L))
|
|
{'Italy': 'Rome', 'US': 'Washington DC', 'France': 'Paris'}
|
|
|
|
Files also support iteration by calling the ``readline()`` method until there
|
|
are no more lines in the file. This means you can read each line of a file like
|
|
this::
|
|
|
|
for line in file:
|
|
# do something for each line
|
|
...
|
|
|
|
Sets can take their contents from an iterable and let you iterate over the set's
|
|
elements::
|
|
|
|
S = {2, 3, 5, 7, 11, 13}
|
|
for i in S:
|
|
print(i)
|
|
|
|
|
|
|
|
Generator expressions and list comprehensions
|
|
=============================================
|
|
|
|
Two common operations on an iterator's output are 1) performing some operation
|
|
for every element, 2) selecting a subset of elements that meet some condition.
|
|
For example, given a list of strings, you might want to strip off trailing
|
|
whitespace from each line or extract all the strings containing a given
|
|
substring.
|
|
|
|
List comprehensions and generator expressions (short form: "listcomps" and
|
|
"genexps") are a concise notation for such operations, borrowed from the
|
|
functional programming language Haskell (http://www.haskell.org/). You can strip
|
|
all the whitespace from a stream of strings with the following code::
|
|
|
|
line_list = [' line 1\n', 'line 2 \n', ...]
|
|
|
|
# Generator expression -- returns iterator
|
|
stripped_iter = (line.strip() for line in line_list)
|
|
|
|
# List comprehension -- returns list
|
|
stripped_list = [line.strip() for line in line_list]
|
|
|
|
You can select only certain elements by adding an ``"if"`` condition::
|
|
|
|
stripped_list = [line.strip() for line in line_list
|
|
if line != ""]
|
|
|
|
With a list comprehension, you get back a Python list; ``stripped_list`` is a
|
|
list containing the resulting lines, not an iterator. Generator expressions
|
|
return an iterator that computes the values as necessary, not needing to
|
|
materialize all the values at once. This means that list comprehensions aren't
|
|
useful if you're working with iterators that return an infinite stream or a very
|
|
large amount of data. Generator expressions are preferable in these situations.
|
|
|
|
Generator expressions are surrounded by parentheses ("()") and list
|
|
comprehensions are surrounded by square brackets ("[]"). Generator expressions
|
|
have the form::
|
|
|
|
( expression for expr in sequence1
|
|
if condition1
|
|
for expr2 in sequence2
|
|
if condition2
|
|
for expr3 in sequence3 ...
|
|
if condition3
|
|
for exprN in sequenceN
|
|
if conditionN )
|
|
|
|
Again, for a list comprehension only the outside brackets are different (square
|
|
brackets instead of parentheses).
|
|
|
|
The elements of the generated output will be the successive values of
|
|
``expression``. The ``if`` clauses are all optional; if present, ``expression``
|
|
is only evaluated and added to the result when ``condition`` is true.
|
|
|
|
Generator expressions always have to be written inside parentheses, but the
|
|
parentheses signalling a function call also count. If you want to create an
|
|
iterator that will be immediately passed to a function you can write::
|
|
|
|
obj_total = sum(obj.count for obj in list_all_objects())
|
|
|
|
The ``for...in`` clauses contain the sequences to be iterated over. The
|
|
sequences do not have to be the same length, because they are iterated over from
|
|
left to right, **not** in parallel. For each element in ``sequence1``,
|
|
``sequence2`` is looped over from the beginning. ``sequence3`` is then looped
|
|
over for each resulting pair of elements from ``sequence1`` and ``sequence2``.
|
|
|
|
To put it another way, a list comprehension or generator expression is
|
|
equivalent to the following Python code::
|
|
|
|
for expr1 in sequence1:
|
|
if not (condition1):
|
|
continue # Skip this element
|
|
for expr2 in sequence2:
|
|
if not (condition2):
|
|
continue # Skip this element
|
|
...
|
|
for exprN in sequenceN:
|
|
if not (conditionN):
|
|
continue # Skip this element
|
|
|
|
# Output the value of
|
|
# the expression.
|
|
|
|
This means that when there are multiple ``for...in`` clauses but no ``if``
|
|
clauses, the length of the resulting output will be equal to the product of the
|
|
lengths of all the sequences. If you have two lists of length 3, the output
|
|
list is 9 elements long:
|
|
|
|
.. doctest::
|
|
:options: +NORMALIZE_WHITESPACE
|
|
|
|
>>> seq1 = 'abc'
|
|
>>> seq2 = (1,2,3)
|
|
>>> [(x,y) for x in seq1 for y in seq2]
|
|
[('a', 1), ('a', 2), ('a', 3),
|
|
('b', 1), ('b', 2), ('b', 3),
|
|
('c', 1), ('c', 2), ('c', 3)]
|
|
|
|
To avoid introducing an ambiguity into Python's grammar, if ``expression`` is
|
|
creating a tuple, it must be surrounded with parentheses. The first list
|
|
comprehension below is a syntax error, while the second one is correct::
|
|
|
|
# Syntax error
|
|
[ x,y for x in seq1 for y in seq2]
|
|
# Correct
|
|
[ (x,y) for x in seq1 for y in seq2]
|
|
|
|
|
|
Generators
|
|
==========
|
|
|
|
Generators are a special class of functions that simplify the task of writing
|
|
iterators. Regular functions compute a value and return it, but generators
|
|
return an iterator that returns a stream of values.
|
|
|
|
You're doubtless familiar with how regular function calls work in Python or C.
|
|
When you call a function, it gets a private namespace where its local variables
|
|
are created. When the function reaches a ``return`` statement, the local
|
|
variables are destroyed and the value is returned to the caller. A later call
|
|
to the same function creates a new private namespace and a fresh set of local
|
|
variables. But, what if the local variables weren't thrown away on exiting a
|
|
function? What if you could later resume the function where it left off? This
|
|
is what generators provide; they can be thought of as resumable functions.
|
|
|
|
Here's the simplest example of a generator function:
|
|
|
|
.. testcode::
|
|
|
|
def generate_ints(N):
|
|
for i in range(N):
|
|
yield i
|
|
|
|
Any function containing a ``yield`` keyword is a generator function; this is
|
|
detected by Python's :term:`bytecode` compiler which compiles the function
|
|
specially as a result.
|
|
|
|
When you call a generator function, it doesn't return a single value; instead it
|
|
returns a generator object that supports the iterator protocol. On executing
|
|
the ``yield`` expression, the generator outputs the value of ``i``, similar to a
|
|
``return`` statement. The big difference between ``yield`` and a ``return``
|
|
statement is that on reaching a ``yield`` the generator's state of execution is
|
|
suspended and local variables are preserved. On the next call to the
|
|
generator's ``.__next__()`` method, the function will resume executing.
|
|
|
|
Here's a sample usage of the ``generate_ints()`` generator:
|
|
|
|
>>> gen = generate_ints(3)
|
|
>>> gen
|
|
<generator object generate_ints at ...>
|
|
>>> next(gen)
|
|
0
|
|
>>> next(gen)
|
|
1
|
|
>>> next(gen)
|
|
2
|
|
>>> next(gen)
|
|
Traceback (most recent call last):
|
|
File "stdin", line 1, in ?
|
|
File "stdin", line 2, in generate_ints
|
|
StopIteration
|
|
|
|
You could equally write ``for i in generate_ints(5)``, or ``a,b,c =
|
|
generate_ints(3)``.
|
|
|
|
Inside a generator function, the ``return`` statement can only be used without a
|
|
value, and signals the end of the procession of values; after executing a
|
|
``return`` the generator cannot return any further values. ``return`` with a
|
|
value, such as ``return 5``, is a syntax error inside a generator function. The
|
|
end of the generator's results can also be indicated by raising
|
|
``StopIteration`` manually, or by just letting the flow of execution fall off
|
|
the bottom of the function.
|
|
|
|
You could achieve the effect of generators manually by writing your own class
|
|
and storing all the local variables of the generator as instance variables. For
|
|
example, returning a list of integers could be done by setting ``self.count`` to
|
|
0, and having the ``__next__()`` method increment ``self.count`` and return it.
|
|
However, for a moderately complicated generator, writing a corresponding class
|
|
can be much messier.
|
|
|
|
The test suite included with Python's library, ``test_generators.py``, contains
|
|
a number of more interesting examples. Here's one generator that implements an
|
|
in-order traversal of a tree using generators recursively. ::
|
|
|
|
# A recursive generator that generates Tree leaves in in-order.
|
|
def inorder(t):
|
|
if t:
|
|
for x in inorder(t.left):
|
|
yield x
|
|
|
|
yield t.label
|
|
|
|
for x in inorder(t.right):
|
|
yield x
|
|
|
|
Two other examples in ``test_generators.py`` produce solutions for the N-Queens
|
|
problem (placing N queens on an NxN chess board so that no queen threatens
|
|
another) and the Knight's Tour (finding a route that takes a knight to every
|
|
square of an NxN chessboard without visiting any square twice).
|
|
|
|
|
|
|
|
Passing values into a generator
|
|
-------------------------------
|
|
|
|
In Python 2.4 and earlier, generators only produced output. Once a generator's
|
|
code was invoked to create an iterator, there was no way to pass any new
|
|
information into the function when its execution is resumed. You could hack
|
|
together this ability by making the generator look at a global variable or by
|
|
passing in some mutable object that callers then modify, but these approaches
|
|
are messy.
|
|
|
|
In Python 2.5 there's a simple way to pass values into a generator.
|
|
:keyword:`yield` became an expression, returning a value that can be assigned to
|
|
a variable or otherwise operated on::
|
|
|
|
val = (yield i)
|
|
|
|
I recommend that you **always** put parentheses around a ``yield`` expression
|
|
when you're doing something with the returned value, as in the above example.
|
|
The parentheses aren't always necessary, but it's easier to always add them
|
|
instead of having to remember when they're needed.
|
|
|
|
(PEP 342 explains the exact rules, which are that a ``yield``-expression must
|
|
always be parenthesized except when it occurs at the top-level expression on the
|
|
right-hand side of an assignment. This means you can write ``val = yield i``
|
|
but have to use parentheses when there's an operation, as in ``val = (yield i)
|
|
+ 12``.)
|
|
|
|
Values are sent into a generator by calling its ``send(value)`` method. This
|
|
method resumes the generator's code and the ``yield`` expression returns the
|
|
specified value. If the regular ``__next__()`` method is called, the ``yield``
|
|
returns ``None``.
|
|
|
|
Here's a simple counter that increments by 1 and allows changing the value of
|
|
the internal counter.
|
|
|
|
.. testcode::
|
|
|
|
def counter (maximum):
|
|
i = 0
|
|
while i < maximum:
|
|
val = (yield i)
|
|
# If value provided, change counter
|
|
if val is not None:
|
|
i = val
|
|
else:
|
|
i += 1
|
|
|
|
And here's an example of changing the counter:
|
|
|
|
>>> it = counter(10)
|
|
>>> next(it)
|
|
0
|
|
>>> next(it)
|
|
1
|
|
>>> it.send(8)
|
|
8
|
|
>>> next(it)
|
|
9
|
|
>>> next(it)
|
|
Traceback (most recent call last):
|
|
File "t.py", line 15, in ?
|
|
it.next()
|
|
StopIteration
|
|
|
|
Because ``yield`` will often be returning ``None``, you should always check for
|
|
this case. Don't just use its value in expressions unless you're sure that the
|
|
``send()`` method will be the only method used resume your generator function.
|
|
|
|
In addition to ``send()``, there are two other new methods on generators:
|
|
|
|
* ``throw(type, value=None, traceback=None)`` is used to raise an exception
|
|
inside the generator; the exception is raised by the ``yield`` expression
|
|
where the generator's execution is paused.
|
|
|
|
* ``close()`` raises a :exc:`GeneratorExit` exception inside the generator to
|
|
terminate the iteration. On receiving this exception, the generator's code
|
|
must either raise :exc:`GeneratorExit` or :exc:`StopIteration`; catching the
|
|
exception and doing anything else is illegal and will trigger a
|
|
:exc:`RuntimeError`. ``close()`` will also be called by Python's garbage
|
|
collector when the generator is garbage-collected.
|
|
|
|
If you need to run cleanup code when a :exc:`GeneratorExit` occurs, I suggest
|
|
using a ``try: ... finally:`` suite instead of catching :exc:`GeneratorExit`.
|
|
|
|
The cumulative effect of these changes is to turn generators from one-way
|
|
producers of information into both producers and consumers.
|
|
|
|
Generators also become **coroutines**, a more generalized form of subroutines.
|
|
Subroutines are entered at one point and exited at another point (the top of the
|
|
function, and a ``return`` statement), but coroutines can be entered, exited,
|
|
and resumed at many different points (the ``yield`` statements).
|
|
|
|
|
|
Built-in functions
|
|
==================
|
|
|
|
Let's look in more detail at built-in functions often used with iterators.
|
|
|
|
Two of Python's built-in functions, :func:`map` and :func:`filter` duplicate the
|
|
features of generator expressions:
|
|
|
|
``map(f, iterA, iterB, ...)`` returns an iterator over the sequence
|
|
``f(iterA[0], iterB[0]), f(iterA[1], iterB[1]), f(iterA[2], iterB[2]), ...``.
|
|
|
|
>>> def upper(s):
|
|
... return s.upper()
|
|
|
|
|
|
>>> list(map(upper, ['sentence', 'fragment']))
|
|
['SENTENCE', 'FRAGMENT']
|
|
>>> [upper(s) for s in ['sentence', 'fragment']]
|
|
['SENTENCE', 'FRAGMENT']
|
|
|
|
You can of course achieve the same effect with a list comprehension.
|
|
|
|
``filter(predicate, iter)`` returns an iterator over all the sequence elements
|
|
that meet a certain condition, and is similarly duplicated by list
|
|
comprehensions. A **predicate** is a function that returns the truth value of
|
|
some condition; for use with :func:`filter`, the predicate must take a single
|
|
value.
|
|
|
|
>>> def is_even(x):
|
|
... return (x % 2) == 0
|
|
|
|
>>> list(filter(is_even, range(10)))
|
|
[0, 2, 4, 6, 8]
|
|
|
|
|
|
This can also be written as a list comprehension:
|
|
|
|
>>> list(x for x in range(10) if is_even(x))
|
|
[0, 2, 4, 6, 8]
|
|
|
|
|
|
``enumerate(iter)`` counts off the elements in the iterable, returning 2-tuples
|
|
containing the count and each element. ::
|
|
|
|
>>> for item in enumerate(['subject', 'verb', 'object']):
|
|
... print(item)
|
|
(0, 'subject')
|
|
(1, 'verb')
|
|
(2, 'object')
|
|
|
|
:func:`enumerate` is often used when looping through a list and recording the
|
|
indexes at which certain conditions are met::
|
|
|
|
f = open('data.txt', 'r')
|
|
for i, line in enumerate(f):
|
|
if line.strip() == '':
|
|
print('Blank line at line #%i' % i)
|
|
|
|
``sorted(iterable, [key=None], [reverse=False])`` collects all the elements of
|
|
the iterable into a list, sorts the list, and returns the sorted result. The
|
|
``key``, and ``reverse`` arguments are passed through to the constructed list's
|
|
``.sort()`` method. ::
|
|
|
|
>>> import random
|
|
>>> # Generate 8 random numbers between [0, 10000)
|
|
>>> rand_list = random.sample(range(10000), 8)
|
|
>>> rand_list
|
|
[769, 7953, 9828, 6431, 8442, 9878, 6213, 2207]
|
|
>>> sorted(rand_list)
|
|
[769, 2207, 6213, 6431, 7953, 8442, 9828, 9878]
|
|
>>> sorted(rand_list, reverse=True)
|
|
[9878, 9828, 8442, 7953, 6431, 6213, 2207, 769]
|
|
|
|
(For a more detailed discussion of sorting, see the Sorting mini-HOWTO in the
|
|
Python wiki at http://wiki.python.org/moin/HowTo/Sorting.)
|
|
|
|
|
|
The ``any(iter)`` and ``all(iter)`` built-ins look at the truth values of an
|
|
iterable's contents. :func:`any` returns True if any element in the iterable is
|
|
a true value, and :func:`all` returns True if all of the elements are true
|
|
values:
|
|
|
|
>>> any([0,1,0])
|
|
True
|
|
>>> any([0,0,0])
|
|
False
|
|
>>> any([1,1,1])
|
|
True
|
|
>>> all([0,1,0])
|
|
False
|
|
>>> all([0,0,0])
|
|
False
|
|
>>> all([1,1,1])
|
|
True
|
|
|
|
|
|
``zip(iterA, iterB, ...)`` takes one element from each iterable and
|
|
returns them in a tuple::
|
|
|
|
zip(['a', 'b', 'c'], (1, 2, 3)) =>
|
|
('a', 1), ('b', 2), ('c', 3)
|
|
|
|
It doesn't construct an in-memory list and exhaust all the input iterators
|
|
before returning; instead tuples are constructed and returned only if they're
|
|
requested. (The technical term for this behaviour is `lazy evaluation
|
|
<http://en.wikipedia.org/wiki/Lazy_evaluation>`__.)
|
|
|
|
This iterator is intended to be used with iterables that are all of the same
|
|
length. If the iterables are of different lengths, the resulting stream will be
|
|
the same length as the shortest iterable. ::
|
|
|
|
zip(['a', 'b'], (1, 2, 3)) =>
|
|
('a', 1), ('b', 2)
|
|
|
|
You should avoid doing this, though, because an element may be taken from the
|
|
longer iterators and discarded. This means you can't go on to use the iterators
|
|
further because you risk skipping a discarded element.
|
|
|
|
|
|
The itertools module
|
|
====================
|
|
|
|
The :mod:`itertools` module contains a number of commonly-used iterators as well
|
|
as functions for combining several iterators. This section will introduce the
|
|
module's contents by showing small examples.
|
|
|
|
The module's functions fall into a few broad classes:
|
|
|
|
* Functions that create a new iterator based on an existing iterator.
|
|
* Functions for treating an iterator's elements as function arguments.
|
|
* Functions for selecting portions of an iterator's output.
|
|
* A function for grouping an iterator's output.
|
|
|
|
Creating new iterators
|
|
----------------------
|
|
|
|
``itertools.count(n)`` returns an infinite stream of integers, increasing by 1
|
|
each time. You can optionally supply the starting number, which defaults to 0::
|
|
|
|
itertools.count() =>
|
|
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ...
|
|
itertools.count(10) =>
|
|
10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
|
|
|
|
``itertools.cycle(iter)`` saves a copy of the contents of a provided iterable
|
|
and returns a new iterator that returns its elements from first to last. The
|
|
new iterator will repeat these elements infinitely. ::
|
|
|
|
itertools.cycle([1,2,3,4,5]) =>
|
|
1, 2, 3, 4, 5, 1, 2, 3, 4, 5, ...
|
|
|
|
``itertools.repeat(elem, [n])`` returns the provided element ``n`` times, or
|
|
returns the element endlessly if ``n`` is not provided. ::
|
|
|
|
itertools.repeat('abc') =>
|
|
abc, abc, abc, abc, abc, abc, abc, abc, abc, abc, ...
|
|
itertools.repeat('abc', 5) =>
|
|
abc, abc, abc, abc, abc
|
|
|
|
``itertools.chain(iterA, iterB, ...)`` takes an arbitrary number of iterables as
|
|
input, and returns all the elements of the first iterator, then all the elements
|
|
of the second, and so on, until all of the iterables have been exhausted. ::
|
|
|
|
itertools.chain(['a', 'b', 'c'], (1, 2, 3)) =>
|
|
a, b, c, 1, 2, 3
|
|
|
|
``itertools.islice(iter, [start], stop, [step])`` returns a stream that's a
|
|
slice of the iterator. With a single ``stop`` argument, it will return the
|
|
first ``stop`` elements. If you supply a starting index, you'll get
|
|
``stop-start`` elements, and if you supply a value for ``step``, elements will
|
|
be skipped accordingly. Unlike Python's string and list slicing, you can't use
|
|
negative values for ``start``, ``stop``, or ``step``. ::
|
|
|
|
itertools.islice(range(10), 8) =>
|
|
0, 1, 2, 3, 4, 5, 6, 7
|
|
itertools.islice(range(10), 2, 8) =>
|
|
2, 3, 4, 5, 6, 7
|
|
itertools.islice(range(10), 2, 8, 2) =>
|
|
2, 4, 6
|
|
|
|
``itertools.tee(iter, [n])`` replicates an iterator; it returns ``n``
|
|
independent iterators that will all return the contents of the source iterator.
|
|
If you don't supply a value for ``n``, the default is 2. Replicating iterators
|
|
requires saving some of the contents of the source iterator, so this can consume
|
|
significant memory if the iterator is large and one of the new iterators is
|
|
consumed more than the others. ::
|
|
|
|
itertools.tee( itertools.count() ) =>
|
|
iterA, iterB
|
|
|
|
where iterA ->
|
|
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ...
|
|
|
|
and iterB ->
|
|
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ...
|
|
|
|
|
|
Calling functions on elements
|
|
-----------------------------
|
|
|
|
The ``operator`` module contains a set of functions corresponding to Python's
|
|
operators. Some examples are ``operator.add(a, b)`` (adds two values),
|
|
``operator.ne(a, b)`` (same as ``a!=b``), and ``operator.attrgetter('id')``
|
|
(returns a callable that fetches the ``"id"`` attribute).
|
|
|
|
``itertools.starmap(func, iter)`` assumes that the iterable will return a stream
|
|
of tuples, and calls ``f()`` using these tuples as the arguments::
|
|
|
|
itertools.starmap(os.path.join,
|
|
[('/usr', 'bin', 'java'), ('/bin', 'python'),
|
|
('/usr', 'bin', 'perl'),('/usr', 'bin', 'ruby')])
|
|
=>
|
|
/usr/bin/java, /bin/python, /usr/bin/perl, /usr/bin/ruby
|
|
|
|
|
|
Selecting elements
|
|
------------------
|
|
|
|
Another group of functions chooses a subset of an iterator's elements based on a
|
|
predicate.
|
|
|
|
``itertools.filterfalse(predicate, iter)`` is the opposite, returning all
|
|
elements for which the predicate returns false::
|
|
|
|
itertools.filterfalse(is_even, itertools.count()) =>
|
|
1, 3, 5, 7, 9, 11, 13, 15, ...
|
|
|
|
``itertools.takewhile(predicate, iter)`` returns elements for as long as the
|
|
predicate returns true. Once the predicate returns false, the iterator will
|
|
signal the end of its results.
|
|
|
|
::
|
|
|
|
def less_than_10(x):
|
|
return (x < 10)
|
|
|
|
itertools.takewhile(less_than_10, itertools.count()) =>
|
|
0, 1, 2, 3, 4, 5, 6, 7, 8, 9
|
|
|
|
itertools.takewhile(is_even, itertools.count()) =>
|
|
0
|
|
|
|
``itertools.dropwhile(predicate, iter)`` discards elements while the predicate
|
|
returns true, and then returns the rest of the iterable's results.
|
|
|
|
::
|
|
|
|
itertools.dropwhile(less_than_10, itertools.count()) =>
|
|
10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
|
|
|
|
itertools.dropwhile(is_even, itertools.count()) =>
|
|
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ...
|
|
|
|
|
|
Grouping elements
|
|
-----------------
|
|
|
|
The last function I'll discuss, ``itertools.groupby(iter, key_func=None)``, is
|
|
the most complicated. ``key_func(elem)`` is a function that can compute a key
|
|
value for each element returned by the iterable. If you don't supply a key
|
|
function, the key is simply each element itself.
|
|
|
|
``groupby()`` collects all the consecutive elements from the underlying iterable
|
|
that have the same key value, and returns a stream of 2-tuples containing a key
|
|
value and an iterator for the elements with that key.
|
|
|
|
::
|
|
|
|
city_list = [('Decatur', 'AL'), ('Huntsville', 'AL'), ('Selma', 'AL'),
|
|
('Anchorage', 'AK'), ('Nome', 'AK'),
|
|
('Flagstaff', 'AZ'), ('Phoenix', 'AZ'), ('Tucson', 'AZ'),
|
|
...
|
|
]
|
|
|
|
def get_state (city_state):
|
|
return city_state[1]
|
|
|
|
itertools.groupby(city_list, get_state) =>
|
|
('AL', iterator-1),
|
|
('AK', iterator-2),
|
|
('AZ', iterator-3), ...
|
|
|
|
where
|
|
iterator-1 =>
|
|
('Decatur', 'AL'), ('Huntsville', 'AL'), ('Selma', 'AL')
|
|
iterator-2 =>
|
|
('Anchorage', 'AK'), ('Nome', 'AK')
|
|
iterator-3 =>
|
|
('Flagstaff', 'AZ'), ('Phoenix', 'AZ'), ('Tucson', 'AZ')
|
|
|
|
``groupby()`` assumes that the underlying iterable's contents will already be
|
|
sorted based on the key. Note that the returned iterators also use the
|
|
underlying iterable, so you have to consume the results of iterator-1 before
|
|
requesting iterator-2 and its corresponding key.
|
|
|
|
|
|
The functools module
|
|
====================
|
|
|
|
The :mod:`functools` module in Python 2.5 contains some higher-order functions.
|
|
A **higher-order function** takes one or more functions as input and returns a
|
|
new function. The most useful tool in this module is the
|
|
:func:`functools.partial` function.
|
|
|
|
For programs written in a functional style, you'll sometimes want to construct
|
|
variants of existing functions that have some of the parameters filled in.
|
|
Consider a Python function ``f(a, b, c)``; you may wish to create a new function
|
|
``g(b, c)`` that's equivalent to ``f(1, b, c)``; you're filling in a value for
|
|
one of ``f()``'s parameters. This is called "partial function application".
|
|
|
|
The constructor for ``partial`` takes the arguments ``(function, arg1, arg2,
|
|
... kwarg1=value1, kwarg2=value2)``. The resulting object is callable, so you
|
|
can just call it to invoke ``function`` with the filled-in arguments.
|
|
|
|
Here's a small but realistic example::
|
|
|
|
import functools
|
|
|
|
def log (message, subsystem):
|
|
"Write the contents of 'message' to the specified subsystem."
|
|
print('%s: %s' % (subsystem, message))
|
|
...
|
|
|
|
server_log = functools.partial(log, subsystem='server')
|
|
server_log('Unable to open socket')
|
|
|
|
``functools.reduce(func, iter, [initial_value])`` cumulatively performs an
|
|
operation on all the iterable's elements and, therefore, can't be applied to
|
|
infinite iterables. (Note it is not in :mod:`builtins`, but in the
|
|
:mod:`functools` module.) ``func`` must be a function that takes two elements
|
|
and returns a single value. :func:`functools.reduce` takes the first two
|
|
elements A and B returned by the iterator and calculates ``func(A, B)``. It
|
|
then requests the third element, C, calculates ``func(func(A, B), C)``, combines
|
|
this result with the fourth element returned, and continues until the iterable
|
|
is exhausted. If the iterable returns no values at all, a :exc:`TypeError`
|
|
exception is raised. If the initial value is supplied, it's used as a starting
|
|
point and ``func(initial_value, A)`` is the first calculation. ::
|
|
|
|
>>> import operator, functools
|
|
>>> functools.reduce(operator.concat, ['A', 'BB', 'C'])
|
|
'ABBC'
|
|
>>> functools.reduce(operator.concat, [])
|
|
Traceback (most recent call last):
|
|
...
|
|
TypeError: reduce() of empty sequence with no initial value
|
|
>>> functools.reduce(operator.mul, [1,2,3], 1)
|
|
6
|
|
>>> functools.reduce(operator.mul, [], 1)
|
|
1
|
|
|
|
If you use :func:`operator.add` with :func:`functools.reduce`, you'll add up all the
|
|
elements of the iterable. This case is so common that there's a special
|
|
built-in called :func:`sum` to compute it:
|
|
|
|
>>> import functools
|
|
>>> functools.reduce(operator.add, [1,2,3,4], 0)
|
|
10
|
|
>>> sum([1,2,3,4])
|
|
10
|
|
>>> sum([])
|
|
0
|
|
|
|
For many uses of :func:`functools.reduce`, though, it can be clearer to just write the
|
|
obvious :keyword:`for` loop::
|
|
|
|
import functools
|
|
# Instead of:
|
|
product = functools.reduce(operator.mul, [1,2,3], 1)
|
|
|
|
# You can write:
|
|
product = 1
|
|
for i in [1,2,3]:
|
|
product *= i
|
|
|
|
|
|
The operator module
|
|
-------------------
|
|
|
|
The :mod:`operator` module was mentioned earlier. It contains a set of
|
|
functions corresponding to Python's operators. These functions are often useful
|
|
in functional-style code because they save you from writing trivial functions
|
|
that perform a single operation.
|
|
|
|
Some of the functions in this module are:
|
|
|
|
* Math operations: ``add()``, ``sub()``, ``mul()``, ``floordiv()``, ``abs()``, ...
|
|
* Logical operations: ``not_()``, ``truth()``.
|
|
* Bitwise operations: ``and_()``, ``or_()``, ``invert()``.
|
|
* Comparisons: ``eq()``, ``ne()``, ``lt()``, ``le()``, ``gt()``, and ``ge()``.
|
|
* Object identity: ``is_()``, ``is_not()``.
|
|
|
|
Consult the operator module's documentation for a complete list.
|
|
|
|
|
|
|
|
The functional module
|
|
---------------------
|
|
|
|
Collin Winter's `functional module <http://oakwinter.com/code/functional/>`__
|
|
provides a number of more advanced tools for functional programming. It also
|
|
reimplements several Python built-ins, trying to make them more intuitive to
|
|
those used to functional programming in other languages.
|
|
|
|
This section contains an introduction to some of the most important functions in
|
|
``functional``; full documentation can be found at `the project's website
|
|
<http://oakwinter.com/code/functional/documentation/>`__.
|
|
|
|
``compose(outer, inner, unpack=False)``
|
|
|
|
The ``compose()`` function implements function composition. In other words, it
|
|
returns a wrapper around the ``outer`` and ``inner`` callables, such that the
|
|
return value from ``inner`` is fed directly to ``outer``. That is, ::
|
|
|
|
>>> def add(a, b):
|
|
... return a + b
|
|
...
|
|
>>> def double(a):
|
|
... return 2 * a
|
|
...
|
|
>>> compose(double, add)(5, 6)
|
|
22
|
|
|
|
is equivalent to ::
|
|
|
|
>>> double(add(5, 6))
|
|
22
|
|
|
|
The ``unpack`` keyword is provided to work around the fact that Python functions
|
|
are not always `fully curried <http://en.wikipedia.org/wiki/Currying>`__. By
|
|
default, it is expected that the ``inner`` function will return a single object
|
|
and that the ``outer`` function will take a single argument. Setting the
|
|
``unpack`` argument causes ``compose`` to expect a tuple from ``inner`` which
|
|
will be expanded before being passed to ``outer``. Put simply, ::
|
|
|
|
compose(f, g)(5, 6)
|
|
|
|
is equivalent to::
|
|
|
|
f(g(5, 6))
|
|
|
|
while ::
|
|
|
|
compose(f, g, unpack=True)(5, 6)
|
|
|
|
is equivalent to::
|
|
|
|
f(*g(5, 6))
|
|
|
|
Even though ``compose()`` only accepts two functions, it's trivial to build up a
|
|
version that will compose any number of functions. We'll use
|
|
:func:`functools.reduce`, ``compose()`` and ``partial()`` (the last of which is
|
|
provided by both ``functional`` and ``functools``). ::
|
|
|
|
from functional import compose, partial
|
|
import functools
|
|
|
|
|
|
multi_compose = partial(functools.reduce, compose)
|
|
|
|
|
|
We can also use ``map()``, ``compose()`` and ``partial()`` to craft a version of
|
|
``"".join(...)`` that converts its arguments to string::
|
|
|
|
from functional import compose, partial
|
|
|
|
join = compose("".join, partial(map, str))
|
|
|
|
|
|
``flip(func)``
|
|
|
|
``flip()`` wraps the callable in ``func`` and causes it to receive its
|
|
non-keyword arguments in reverse order. ::
|
|
|
|
>>> def triple(a, b, c):
|
|
... return (a, b, c)
|
|
...
|
|
>>> triple(5, 6, 7)
|
|
(5, 6, 7)
|
|
>>>
|
|
>>> flipped_triple = flip(triple)
|
|
>>> flipped_triple(5, 6, 7)
|
|
(7, 6, 5)
|
|
|
|
``foldl(func, start, iterable)``
|
|
|
|
``foldl()`` takes a binary function, a starting value (usually some kind of
|
|
'zero'), and an iterable. The function is applied to the starting value and the
|
|
first element of the list, then the result of that and the second element of the
|
|
list, then the result of that and the third element of the list, and so on.
|
|
|
|
This means that a call such as::
|
|
|
|
foldl(f, 0, [1, 2, 3])
|
|
|
|
is equivalent to::
|
|
|
|
f(f(f(0, 1), 2), 3)
|
|
|
|
|
|
``foldl()`` is roughly equivalent to the following recursive function::
|
|
|
|
def foldl(func, start, seq):
|
|
if len(seq) == 0:
|
|
return start
|
|
|
|
return foldl(func, func(start, seq[0]), seq[1:])
|
|
|
|
Speaking of equivalence, the above ``foldl`` call can be expressed in terms of
|
|
the built-in :func:`functools.reduce` like so::
|
|
|
|
import functools
|
|
functools.reduce(f, [1, 2, 3], 0)
|
|
|
|
|
|
We can use ``foldl()``, ``operator.concat()`` and ``partial()`` to write a
|
|
cleaner, more aesthetically-pleasing version of Python's ``"".join(...)``
|
|
idiom::
|
|
|
|
from functional import foldl, partial from operator import concat
|
|
|
|
join = partial(foldl, concat, "")
|
|
|
|
|
|
Small functions and the lambda expression
|
|
=========================================
|
|
|
|
When writing functional-style programs, you'll often need little functions that
|
|
act as predicates or that combine elements in some way.
|
|
|
|
If there's a Python built-in or a module function that's suitable, you don't
|
|
need to define a new function at all::
|
|
|
|
stripped_lines = [line.strip() for line in lines]
|
|
existing_files = filter(os.path.exists, file_list)
|
|
|
|
If the function you need doesn't exist, you need to write it. One way to write
|
|
small functions is to use the ``lambda`` statement. ``lambda`` takes a number
|
|
of parameters and an expression combining these parameters, and creates a small
|
|
function that returns the value of the expression::
|
|
|
|
lowercase = lambda x: x.lower()
|
|
|
|
print_assign = lambda name, value: name + '=' + str(value)
|
|
|
|
adder = lambda x, y: x+y
|
|
|
|
An alternative is to just use the ``def`` statement and define a function in the
|
|
usual way::
|
|
|
|
def lowercase(x):
|
|
return x.lower()
|
|
|
|
def print_assign(name, value):
|
|
return name + '=' + str(value)
|
|
|
|
def adder(x,y):
|
|
return x + y
|
|
|
|
Which alternative is preferable? That's a style question; my usual course is to
|
|
avoid using ``lambda``.
|
|
|
|
One reason for my preference is that ``lambda`` is quite limited in the
|
|
functions it can define. The result has to be computable as a single
|
|
expression, which means you can't have multiway ``if... elif... else``
|
|
comparisons or ``try... except`` statements. If you try to do too much in a
|
|
``lambda`` statement, you'll end up with an overly complicated expression that's
|
|
hard to read. Quick, what's the following code doing?
|
|
|
|
::
|
|
|
|
import functools
|
|
total = functools.reduce(lambda a, b: (0, a[1] + b[1]), items)[1]
|
|
|
|
You can figure it out, but it takes time to disentangle the expression to figure
|
|
out what's going on. Using a short nested ``def`` statements makes things a
|
|
little bit better::
|
|
|
|
import functools
|
|
def combine (a, b):
|
|
return 0, a[1] + b[1]
|
|
|
|
total = functools.reduce(combine, items)[1]
|
|
|
|
But it would be best of all if I had simply used a ``for`` loop::
|
|
|
|
total = 0
|
|
for a, b in items:
|
|
total += b
|
|
|
|
Or the :func:`sum` built-in and a generator expression::
|
|
|
|
total = sum(b for a,b in items)
|
|
|
|
Many uses of :func:`functools.reduce` are clearer when written as ``for`` loops.
|
|
|
|
Fredrik Lundh once suggested the following set of rules for refactoring uses of
|
|
``lambda``:
|
|
|
|
1) Write a lambda function.
|
|
2) Write a comment explaining what the heck that lambda does.
|
|
3) Study the comment for a while, and think of a name that captures the essence
|
|
of the comment.
|
|
4) Convert the lambda to a def statement, using that name.
|
|
5) Remove the comment.
|
|
|
|
I really like these rules, but you're free to disagree
|
|
about whether this lambda-free style is better.
|
|
|
|
|
|
Revision History and Acknowledgements
|
|
=====================================
|
|
|
|
The author would like to thank the following people for offering suggestions,
|
|
corrections and assistance with various drafts of this article: Ian Bicking,
|
|
Nick Coghlan, Nick Efford, Raymond Hettinger, Jim Jewett, Mike Krell, Leandro
|
|
Lameiro, Jussi Salmela, Collin Winter, Blake Winton.
|
|
|
|
Version 0.1: posted June 30 2006.
|
|
|
|
Version 0.11: posted July 1 2006. Typo fixes.
|
|
|
|
Version 0.2: posted July 10 2006. Merged genexp and listcomp sections into one.
|
|
Typo fixes.
|
|
|
|
Version 0.21: Added more references suggested on the tutor mailing list.
|
|
|
|
Version 0.30: Adds a section on the ``functional`` module written by Collin
|
|
Winter; adds short section on the operator module; a few other edits.
|
|
|
|
|
|
References
|
|
==========
|
|
|
|
General
|
|
-------
|
|
|
|
**Structure and Interpretation of Computer Programs**, by Harold Abelson and
|
|
Gerald Jay Sussman with Julie Sussman. Full text at
|
|
http://mitpress.mit.edu/sicp/. In this classic textbook of computer science,
|
|
chapters 2 and 3 discuss the use of sequences and streams to organize the data
|
|
flow inside a program. The book uses Scheme for its examples, but many of the
|
|
design approaches described in these chapters are applicable to functional-style
|
|
Python code.
|
|
|
|
http://www.defmacro.org/ramblings/fp.html: A general introduction to functional
|
|
programming that uses Java examples and has a lengthy historical introduction.
|
|
|
|
http://en.wikipedia.org/wiki/Functional_programming: General Wikipedia entry
|
|
describing functional programming.
|
|
|
|
http://en.wikipedia.org/wiki/Coroutine: Entry for coroutines.
|
|
|
|
http://en.wikipedia.org/wiki/Currying: Entry for the concept of currying.
|
|
|
|
Python-specific
|
|
---------------
|
|
|
|
http://gnosis.cx/TPiP/: The first chapter of David Mertz's book
|
|
:title-reference:`Text Processing in Python` discusses functional programming
|
|
for text processing, in the section titled "Utilizing Higher-Order Functions in
|
|
Text Processing".
|
|
|
|
Mertz also wrote a 3-part series of articles on functional programming
|
|
for IBM's DeveloperWorks site; see
|
|
`part 1 <http://www-128.ibm.com/developerworks/library/l-prog.html>`__,
|
|
`part 2 <http://www-128.ibm.com/developerworks/library/l-prog2.html>`__, and
|
|
`part 3 <http://www-128.ibm.com/developerworks/linux/library/l-prog3.html>`__,
|
|
|
|
|
|
Python documentation
|
|
--------------------
|
|
|
|
Documentation for the :mod:`itertools` module.
|
|
|
|
Documentation for the :mod:`operator` module.
|
|
|
|
:pep:`289`: "Generator Expressions"
|
|
|
|
:pep:`342`: "Coroutines via Enhanced Generators" describes the new generator
|
|
features in Python 2.5.
|
|
|
|
.. comment
|
|
|
|
Topics to place
|
|
-----------------------------
|
|
|
|
XXX os.walk()
|
|
|
|
XXX Need a large example.
|
|
|
|
But will an example add much? I'll post a first draft and see
|
|
what the comments say.
|
|
|
|
.. comment
|
|
|
|
Original outline:
|
|
Introduction
|
|
Idea of FP
|
|
Programs built out of functions
|
|
Functions are strictly input-output, no internal state
|
|
Opposed to OO programming, where objects have state
|
|
|
|
Why FP?
|
|
Formal provability
|
|
Assignment is difficult to reason about
|
|
Not very relevant to Python
|
|
Modularity
|
|
Small functions that do one thing
|
|
Debuggability:
|
|
Easy to test due to lack of state
|
|
Easy to verify output from intermediate steps
|
|
Composability
|
|
You assemble a toolbox of functions that can be mixed
|
|
|
|
Tackling a problem
|
|
Need a significant example
|
|
|
|
Iterators
|
|
Generators
|
|
The itertools module
|
|
List comprehensions
|
|
Small functions and the lambda statement
|
|
Built-in functions
|
|
map
|
|
filter
|
|
|
|
.. comment
|
|
|
|
Handy little function for printing part of an iterator -- used
|
|
while writing this document.
|
|
|
|
import itertools
|
|
def print_iter(it):
|
|
slice = itertools.islice(it, 10)
|
|
for elem in slice[:-1]:
|
|
sys.stdout.write(str(elem))
|
|
sys.stdout.write(', ')
|
|
print(elem[-1])
|
|
|
|
|