Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 1 | ******************************** |
| 2 | Functional Programming HOWTO |
| 3 | ******************************** |
| 4 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 5 | :Author: A. M. Kuchling |
Christian Heimes | 0449f63 | 2007-12-15 01:27:15 +0000 | [diff] [blame] | 6 | :Release: 0.31 |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 7 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 8 | In this document, we'll take a tour of Python's features suitable for |
| 9 | implementing programs in a functional style. After an introduction to the |
| 10 | concepts of functional programming, we'll look at language features such as |
Georg Brandl | 9afde1c | 2007-11-01 20:32:30 +0000 | [diff] [blame] | 11 | :term:`iterator`\s and :term:`generator`\s and relevant library modules such as |
| 12 | :mod:`itertools` and :mod:`functools`. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 13 | |
| 14 | |
| 15 | Introduction |
| 16 | ============ |
| 17 | |
| 18 | This section explains the basic concept of functional programming; if you're |
| 19 | just interested in learning about Python language features, skip to the next |
| 20 | section. |
| 21 | |
| 22 | Programming languages support decomposing problems in several different ways: |
| 23 | |
| 24 | * Most programming languages are **procedural**: programs are lists of |
| 25 | instructions that tell the computer what to do with the program's input. C, |
| 26 | Pascal, and even Unix shells are procedural languages. |
| 27 | |
| 28 | * In **declarative** languages, you write a specification that describes the |
| 29 | problem to be solved, and the language implementation figures out how to |
| 30 | perform the computation efficiently. SQL is the declarative language you're |
| 31 | most likely to be familiar with; a SQL query describes the data set you want |
| 32 | to retrieve, and the SQL engine decides whether to scan tables or use indexes, |
| 33 | which subclauses should be performed first, etc. |
| 34 | |
| 35 | * **Object-oriented** programs manipulate collections of objects. Objects have |
| 36 | internal state and support methods that query or modify this internal state in |
| 37 | some way. Smalltalk and Java are object-oriented languages. C++ and Python |
| 38 | are languages that support object-oriented programming, but don't force the |
| 39 | use of object-oriented features. |
| 40 | |
| 41 | * **Functional** programming decomposes a problem into a set of functions. |
| 42 | Ideally, functions only take inputs and produce outputs, and don't have any |
| 43 | internal state that affects the output produced for a given input. Well-known |
| 44 | functional languages include the ML family (Standard ML, OCaml, and other |
| 45 | variants) and Haskell. |
| 46 | |
Christian Heimes | 0449f63 | 2007-12-15 01:27:15 +0000 | [diff] [blame] | 47 | The designers of some computer languages choose to emphasize one |
| 48 | particular approach to programming. This often makes it difficult to |
| 49 | write programs that use a different approach. Other languages are |
| 50 | multi-paradigm languages that support several different approaches. |
| 51 | Lisp, C++, and Python are multi-paradigm; you can write programs or |
| 52 | libraries that are largely procedural, object-oriented, or functional |
| 53 | in all of these languages. In a large program, different sections |
| 54 | might be written using different approaches; the GUI might be |
| 55 | object-oriented while the processing logic is procedural or |
| 56 | functional, for example. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 57 | |
| 58 | In a functional program, input flows through a set of functions. Each function |
Christian Heimes | 0449f63 | 2007-12-15 01:27:15 +0000 | [diff] [blame] | 59 | operates on its input and produces some output. Functional style discourages |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 60 | functions with side effects that modify internal state or make other changes |
| 61 | that aren't visible in the function's return value. Functions that have no side |
| 62 | effects at all are called **purely functional**. Avoiding side effects means |
| 63 | not using data structures that get updated as a program runs; every function's |
| 64 | output must only depend on its input. |
| 65 | |
| 66 | Some languages are very strict about purity and don't even have assignment |
| 67 | statements such as ``a=3`` or ``c = a + b``, but it's difficult to avoid all |
| 68 | side effects. Printing to the screen or writing to a disk file are side |
Georg Brandl | 0df7979 | 2008-10-04 18:33:26 +0000 | [diff] [blame] | 69 | effects, for example. For example, in Python a call to the :func:`print` or |
| 70 | :func:`time.sleep` function both return no useful value; they're only called for |
| 71 | their side effects of sending some text to the screen or pausing execution for a |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 72 | second. |
| 73 | |
| 74 | Python programs written in functional style usually won't go to the extreme of |
| 75 | avoiding all I/O or all assignments; instead, they'll provide a |
| 76 | functional-appearing interface but will use non-functional features internally. |
| 77 | For example, the implementation of a function will still use assignments to |
| 78 | local variables, but won't modify global variables or have other side effects. |
| 79 | |
| 80 | Functional programming can be considered the opposite of object-oriented |
| 81 | programming. Objects are little capsules containing some internal state along |
| 82 | with a collection of method calls that let you modify this state, and programs |
| 83 | consist of making the right set of state changes. Functional programming wants |
| 84 | to avoid state changes as much as possible and works with data flowing between |
| 85 | functions. In Python you might combine the two approaches by writing functions |
| 86 | that take and return instances representing objects in your application (e-mail |
| 87 | messages, transactions, etc.). |
| 88 | |
| 89 | Functional design may seem like an odd constraint to work under. Why should you |
| 90 | avoid objects and side effects? There are theoretical and practical advantages |
| 91 | to the functional style: |
| 92 | |
| 93 | * Formal provability. |
| 94 | * Modularity. |
| 95 | * Composability. |
| 96 | * Ease of debugging and testing. |
| 97 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 98 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 99 | Formal provability |
| 100 | ------------------ |
| 101 | |
| 102 | A theoretical benefit is that it's easier to construct a mathematical proof that |
| 103 | a functional program is correct. |
| 104 | |
| 105 | For a long time researchers have been interested in finding ways to |
| 106 | mathematically prove programs correct. This is different from testing a program |
| 107 | on numerous inputs and concluding that its output is usually correct, or reading |
| 108 | a program's source code and concluding that the code looks right; the goal is |
| 109 | instead a rigorous proof that a program produces the right result for all |
| 110 | possible inputs. |
| 111 | |
| 112 | The technique used to prove programs correct is to write down **invariants**, |
| 113 | properties of the input data and of the program's variables that are always |
| 114 | true. For each line of code, you then show that if invariants X and Y are true |
| 115 | **before** the line is executed, the slightly different invariants X' and Y' are |
| 116 | true **after** the line is executed. This continues until you reach the end of |
| 117 | the program, at which point the invariants should match the desired conditions |
| 118 | on the program's output. |
| 119 | |
| 120 | Functional programming's avoidance of assignments arose because assignments are |
| 121 | difficult to handle with this technique; assignments can break invariants that |
| 122 | were true before the assignment without producing any new invariants that can be |
| 123 | propagated onward. |
| 124 | |
| 125 | Unfortunately, proving programs correct is largely impractical and not relevant |
| 126 | to Python software. Even trivial programs require proofs that are several pages |
| 127 | long; the proof of correctness for a moderately complicated program would be |
| 128 | enormous, and few or none of the programs you use daily (the Python interpreter, |
| 129 | your XML parser, your web browser) could be proven correct. Even if you wrote |
| 130 | down or generated a proof, there would then be the question of verifying the |
| 131 | proof; maybe there's an error in it, and you wrongly believe you've proved the |
| 132 | program correct. |
| 133 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 134 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 135 | Modularity |
| 136 | ---------- |
| 137 | |
| 138 | A more practical benefit of functional programming is that it forces you to |
| 139 | break apart your problem into small pieces. Programs are more modular as a |
| 140 | result. It's easier to specify and write a small function that does one thing |
| 141 | than a large function that performs a complicated transformation. Small |
| 142 | functions are also easier to read and to check for errors. |
| 143 | |
| 144 | |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 145 | Ease of debugging and testing |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 146 | ----------------------------- |
| 147 | |
| 148 | Testing and debugging a functional-style program is easier. |
| 149 | |
| 150 | Debugging is simplified because functions are generally small and clearly |
| 151 | specified. When a program doesn't work, each function is an interface point |
| 152 | where you can check that the data are correct. You can look at the intermediate |
| 153 | inputs and outputs to quickly isolate the function that's responsible for a bug. |
| 154 | |
| 155 | Testing is easier because each function is a potential subject for a unit test. |
| 156 | Functions don't depend on system state that needs to be replicated before |
| 157 | running a test; instead you only have to synthesize the right input and then |
| 158 | check that the output matches expectations. |
| 159 | |
| 160 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 161 | Composability |
| 162 | ------------- |
| 163 | |
| 164 | As you work on a functional-style program, you'll write a number of functions |
| 165 | with varying inputs and outputs. Some of these functions will be unavoidably |
| 166 | specialized to a particular application, but others will be useful in a wide |
| 167 | variety of programs. For example, a function that takes a directory path and |
| 168 | returns all the XML files in the directory, or a function that takes a filename |
| 169 | and returns its contents, can be applied to many different situations. |
| 170 | |
| 171 | Over time you'll form a personal library of utilities. Often you'll assemble |
| 172 | new programs by arranging existing functions in a new configuration and writing |
| 173 | a few functions specialized for the current task. |
| 174 | |
| 175 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 176 | Iterators |
| 177 | ========= |
| 178 | |
| 179 | I'll start by looking at a Python language feature that's an important |
| 180 | foundation for writing functional-style programs: iterators. |
| 181 | |
| 182 | An iterator is an object representing a stream of data; this object returns the |
| 183 | data one element at a time. A Python iterator must support a method called |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 184 | :meth:`~iterator.__next__` that takes no arguments and always returns the next |
| 185 | element of the stream. If there are no more elements in the stream, |
| 186 | :meth:`~iterator.__next__` must raise the :exc:`StopIteration` exception. |
| 187 | Iterators don't have to be finite, though; it's perfectly reasonable to write |
| 188 | an iterator that produces an infinite stream of data. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 189 | |
| 190 | The built-in :func:`iter` function takes an arbitrary object and tries to return |
| 191 | an iterator that will return the object's contents or elements, raising |
| 192 | :exc:`TypeError` if the object doesn't support iteration. Several of Python's |
| 193 | built-in data types support iteration, the most common being lists and |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 194 | dictionaries. An object is called :term:`iterable` if you can get an iterator |
| 195 | for it. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 196 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 197 | You can experiment with the iteration interface manually: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 198 | |
| 199 | >>> L = [1,2,3] |
| 200 | >>> it = iter(L) |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 201 | >>> it #doctest: +ELLIPSIS |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 202 | <...iterator object at ...> |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 203 | >>> it.__next__() # same as next(it) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 204 | 1 |
Benjamin Peterson | e7c78b2 | 2008-07-03 20:28:26 +0000 | [diff] [blame] | 205 | >>> next(it) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 206 | 2 |
Benjamin Peterson | e7c78b2 | 2008-07-03 20:28:26 +0000 | [diff] [blame] | 207 | >>> next(it) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 208 | 3 |
Benjamin Peterson | e7c78b2 | 2008-07-03 20:28:26 +0000 | [diff] [blame] | 209 | >>> next(it) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 210 | Traceback (most recent call last): |
| 211 | File "<stdin>", line 1, in ? |
| 212 | StopIteration |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 213 | >>> |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 214 | |
| 215 | Python expects iterable objects in several different contexts, the most |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 216 | important being the :keyword:`for` statement. In the statement ``for X in Y``, |
| 217 | Y must be an iterator or some object for which :func:`iter` can create an |
| 218 | iterator. These two statements are equivalent:: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 219 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 220 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 221 | for i in iter(obj): |
Neal Norwitz | 752abd0 | 2008-05-13 04:55:24 +0000 | [diff] [blame] | 222 | print(i) |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 223 | |
| 224 | for i in obj: |
Neal Norwitz | 752abd0 | 2008-05-13 04:55:24 +0000 | [diff] [blame] | 225 | print(i) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 226 | |
| 227 | Iterators can be materialized as lists or tuples by using the :func:`list` or |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 228 | :func:`tuple` constructor functions: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 229 | |
| 230 | >>> L = [1,2,3] |
| 231 | >>> iterator = iter(L) |
| 232 | >>> t = tuple(iterator) |
| 233 | >>> t |
| 234 | (1, 2, 3) |
| 235 | |
| 236 | Sequence unpacking also supports iterators: if you know an iterator will return |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 237 | N elements, you can unpack them into an N-tuple: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 238 | |
| 239 | >>> L = [1,2,3] |
| 240 | >>> iterator = iter(L) |
| 241 | >>> a,b,c = iterator |
| 242 | >>> a,b,c |
| 243 | (1, 2, 3) |
| 244 | |
| 245 | Built-in functions such as :func:`max` and :func:`min` can take a single |
| 246 | iterator argument and will return the largest or smallest element. The ``"in"`` |
| 247 | and ``"not in"`` operators also support iterators: ``X in iterator`` is true if |
| 248 | X is found in the stream returned by the iterator. You'll run into obvious |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 249 | problems if the iterator is infinite; :func:`max`, :func:`min` |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 250 | will never return, and if the element X never appears in the stream, the |
Sandro Tosi | dd7c552 | 2012-08-15 21:37:35 +0200 | [diff] [blame] | 251 | ``"in"`` and ``"not in"`` operators won't return either. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 252 | |
| 253 | Note that you can only go forward in an iterator; there's no way to get the |
| 254 | previous element, reset the iterator, or make a copy of it. Iterator objects |
| 255 | can optionally provide these additional capabilities, but the iterator protocol |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 256 | only specifies the :meth:`~iterator.__next__` method. Functions may therefore |
| 257 | consume all of the iterator's output, and if you need to do something different |
| 258 | with the same stream, you'll have to create a new iterator. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 259 | |
| 260 | |
| 261 | |
| 262 | Data Types That Support Iterators |
| 263 | --------------------------------- |
| 264 | |
| 265 | We've already seen how lists and tuples support iterators. In fact, any Python |
| 266 | sequence type, such as strings, will automatically support creation of an |
| 267 | iterator. |
| 268 | |
| 269 | Calling :func:`iter` on a dictionary returns an iterator that will loop over the |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 270 | dictionary's keys:: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 271 | |
| 272 | >>> m = {'Jan': 1, 'Feb': 2, 'Mar': 3, 'Apr': 4, 'May': 5, 'Jun': 6, |
| 273 | ... 'Jul': 7, 'Aug': 8, 'Sep': 9, 'Oct': 10, 'Nov': 11, 'Dec': 12} |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 274 | >>> for key in m: #doctest: +SKIP |
Georg Brandl | 6911e3c | 2007-09-04 07:15:32 +0000 | [diff] [blame] | 275 | ... print(key, m[key]) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 276 | Mar 3 |
| 277 | Feb 2 |
| 278 | Aug 8 |
| 279 | Sep 9 |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 280 | Apr 4 |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 281 | Jun 6 |
| 282 | Jul 7 |
| 283 | Jan 1 |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 284 | May 5 |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 285 | Nov 11 |
| 286 | Dec 12 |
| 287 | Oct 10 |
| 288 | |
| 289 | Note that the order is essentially random, because it's based on the hash |
| 290 | ordering of the objects in the dictionary. |
| 291 | |
Fred Drake | 2e74878 | 2007-09-04 17:33:11 +0000 | [diff] [blame] | 292 | Applying :func:`iter` to a dictionary always loops over the keys, but |
| 293 | dictionaries have methods that return other iterators. If you want to iterate |
| 294 | over values or key/value pairs, you can explicitly call the |
Chris Jerdonek | 006d907 | 2012-10-12 20:28:26 -0700 | [diff] [blame] | 295 | :meth:`~dict.values` or :meth:`~dict.items` methods to get an appropriate |
| 296 | iterator. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 297 | |
| 298 | The :func:`dict` constructor can accept an iterator that returns a finite stream |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 299 | of ``(key, value)`` tuples: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 300 | |
| 301 | >>> L = [('Italy', 'Rome'), ('France', 'Paris'), ('US', 'Washington DC')] |
Chris Jerdonek | 006d907 | 2012-10-12 20:28:26 -0700 | [diff] [blame] | 302 | >>> dict(iter(L)) #doctest: +SKIP |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 303 | {'Italy': 'Rome', 'US': 'Washington DC', 'France': 'Paris'} |
| 304 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 305 | Files also support iteration by calling the :meth:`~io.TextIOBase.readline` |
| 306 | method until there are no more lines in the file. This means you can read each |
| 307 | line of a file like this:: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 308 | |
| 309 | for line in file: |
| 310 | # do something for each line |
| 311 | ... |
| 312 | |
| 313 | Sets can take their contents from an iterable and let you iterate over the set's |
| 314 | elements:: |
| 315 | |
Georg Brandl | f694518 | 2008-02-01 11:56:49 +0000 | [diff] [blame] | 316 | S = {2, 3, 5, 7, 11, 13} |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 317 | for i in S: |
Georg Brandl | 6911e3c | 2007-09-04 07:15:32 +0000 | [diff] [blame] | 318 | print(i) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 319 | |
| 320 | |
| 321 | |
| 322 | Generator expressions and list comprehensions |
| 323 | ============================================= |
| 324 | |
| 325 | Two common operations on an iterator's output are 1) performing some operation |
| 326 | for every element, 2) selecting a subset of elements that meet some condition. |
| 327 | For example, given a list of strings, you might want to strip off trailing |
| 328 | whitespace from each line or extract all the strings containing a given |
| 329 | substring. |
| 330 | |
| 331 | List comprehensions and generator expressions (short form: "listcomps" and |
| 332 | "genexps") are a concise notation for such operations, borrowed from the |
Ezio Melotti | 19192dd | 2010-04-05 13:25:51 +0000 | [diff] [blame] | 333 | functional programming language Haskell (http://www.haskell.org/). You can strip |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 334 | all the whitespace from a stream of strings with the following code:: |
| 335 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 336 | line_list = [' line 1\n', 'line 2 \n', ...] |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 337 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 338 | # Generator expression -- returns iterator |
| 339 | stripped_iter = (line.strip() for line in line_list) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 340 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 341 | # List comprehension -- returns list |
| 342 | stripped_list = [line.strip() for line in line_list] |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 343 | |
| 344 | You can select only certain elements by adding an ``"if"`` condition:: |
| 345 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 346 | stripped_list = [line.strip() for line in line_list |
| 347 | if line != ""] |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 348 | |
| 349 | With a list comprehension, you get back a Python list; ``stripped_list`` is a |
| 350 | list containing the resulting lines, not an iterator. Generator expressions |
| 351 | return an iterator that computes the values as necessary, not needing to |
| 352 | materialize all the values at once. This means that list comprehensions aren't |
| 353 | useful if you're working with iterators that return an infinite stream or a very |
| 354 | large amount of data. Generator expressions are preferable in these situations. |
| 355 | |
| 356 | Generator expressions are surrounded by parentheses ("()") and list |
| 357 | comprehensions are surrounded by square brackets ("[]"). Generator expressions |
| 358 | have the form:: |
| 359 | |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 360 | ( expression for expr in sequence1 |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 361 | if condition1 |
| 362 | for expr2 in sequence2 |
| 363 | if condition2 |
| 364 | for expr3 in sequence3 ... |
| 365 | if condition3 |
| 366 | for exprN in sequenceN |
| 367 | if conditionN ) |
| 368 | |
| 369 | Again, for a list comprehension only the outside brackets are different (square |
| 370 | brackets instead of parentheses). |
| 371 | |
| 372 | The elements of the generated output will be the successive values of |
| 373 | ``expression``. The ``if`` clauses are all optional; if present, ``expression`` |
| 374 | is only evaluated and added to the result when ``condition`` is true. |
| 375 | |
| 376 | Generator expressions always have to be written inside parentheses, but the |
| 377 | parentheses signalling a function call also count. If you want to create an |
| 378 | iterator that will be immediately passed to a function you can write:: |
| 379 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 380 | obj_total = sum(obj.count for obj in list_all_objects()) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 381 | |
| 382 | The ``for...in`` clauses contain the sequences to be iterated over. The |
| 383 | sequences do not have to be the same length, because they are iterated over from |
| 384 | left to right, **not** in parallel. For each element in ``sequence1``, |
| 385 | ``sequence2`` is looped over from the beginning. ``sequence3`` is then looped |
| 386 | over for each resulting pair of elements from ``sequence1`` and ``sequence2``. |
| 387 | |
| 388 | To put it another way, a list comprehension or generator expression is |
| 389 | equivalent to the following Python code:: |
| 390 | |
| 391 | for expr1 in sequence1: |
| 392 | if not (condition1): |
| 393 | continue # Skip this element |
| 394 | for expr2 in sequence2: |
| 395 | if not (condition2): |
| 396 | continue # Skip this element |
| 397 | ... |
| 398 | for exprN in sequenceN: |
| 399 | if not (conditionN): |
| 400 | continue # Skip this element |
| 401 | |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 402 | # Output the value of |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 403 | # the expression. |
| 404 | |
| 405 | This means that when there are multiple ``for...in`` clauses but no ``if`` |
| 406 | clauses, the length of the resulting output will be equal to the product of the |
| 407 | lengths of all the sequences. If you have two lists of length 3, the output |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 408 | list is 9 elements long: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 409 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 410 | >>> seq1 = 'abc' |
| 411 | >>> seq2 = (1,2,3) |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 412 | >>> [(x, y) for x in seq1 for y in seq2] #doctest: +NORMALIZE_WHITESPACE |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 413 | [('a', 1), ('a', 2), ('a', 3), |
| 414 | ('b', 1), ('b', 2), ('b', 3), |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 415 | ('c', 1), ('c', 2), ('c', 3)] |
| 416 | |
| 417 | To avoid introducing an ambiguity into Python's grammar, if ``expression`` is |
| 418 | creating a tuple, it must be surrounded with parentheses. The first list |
| 419 | comprehension below is a syntax error, while the second one is correct:: |
| 420 | |
| 421 | # Syntax error |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 422 | [x, y for x in seq1 for y in seq2] |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 423 | # Correct |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 424 | [(x, y) for x in seq1 for y in seq2] |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 425 | |
| 426 | |
| 427 | Generators |
| 428 | ========== |
| 429 | |
| 430 | Generators are a special class of functions that simplify the task of writing |
| 431 | iterators. Regular functions compute a value and return it, but generators |
| 432 | return an iterator that returns a stream of values. |
| 433 | |
| 434 | You're doubtless familiar with how regular function calls work in Python or C. |
| 435 | When you call a function, it gets a private namespace where its local variables |
| 436 | are created. When the function reaches a ``return`` statement, the local |
| 437 | variables are destroyed and the value is returned to the caller. A later call |
| 438 | to the same function creates a new private namespace and a fresh set of local |
| 439 | variables. But, what if the local variables weren't thrown away on exiting a |
| 440 | function? What if you could later resume the function where it left off? This |
| 441 | is what generators provide; they can be thought of as resumable functions. |
| 442 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 443 | Here's the simplest example of a generator function: |
| 444 | |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 445 | >>> def generate_ints(N): |
| 446 | ... for i in range(N): |
| 447 | ... yield i |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 448 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 449 | Any function containing a :keyword:`yield` keyword is a generator function; |
| 450 | this is detected by Python's :term:`bytecode` compiler which compiles the |
| 451 | function specially as a result. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 452 | |
| 453 | When you call a generator function, it doesn't return a single value; instead it |
| 454 | returns a generator object that supports the iterator protocol. On executing |
| 455 | the ``yield`` expression, the generator outputs the value of ``i``, similar to a |
| 456 | ``return`` statement. The big difference between ``yield`` and a ``return`` |
| 457 | statement is that on reaching a ``yield`` the generator's state of execution is |
| 458 | suspended and local variables are preserved. On the next call to the |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 459 | generator's :meth:`~generator.__next__` method, the function will resume |
| 460 | executing. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 461 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 462 | Here's a sample usage of the ``generate_ints()`` generator: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 463 | |
| 464 | >>> gen = generate_ints(3) |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 465 | >>> gen #doctest: +ELLIPSIS |
Benjamin Peterson | 25c95f1 | 2009-05-08 20:42:26 +0000 | [diff] [blame] | 466 | <generator object generate_ints at ...> |
Benjamin Peterson | e7c78b2 | 2008-07-03 20:28:26 +0000 | [diff] [blame] | 467 | >>> next(gen) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 468 | 0 |
Benjamin Peterson | e7c78b2 | 2008-07-03 20:28:26 +0000 | [diff] [blame] | 469 | >>> next(gen) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 470 | 1 |
Benjamin Peterson | e7c78b2 | 2008-07-03 20:28:26 +0000 | [diff] [blame] | 471 | >>> next(gen) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 472 | 2 |
Benjamin Peterson | e7c78b2 | 2008-07-03 20:28:26 +0000 | [diff] [blame] | 473 | >>> next(gen) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 474 | Traceback (most recent call last): |
| 475 | File "stdin", line 1, in ? |
| 476 | File "stdin", line 2, in generate_ints |
| 477 | StopIteration |
| 478 | |
| 479 | You could equally write ``for i in generate_ints(5)``, or ``a,b,c = |
| 480 | generate_ints(3)``. |
| 481 | |
| 482 | Inside a generator function, the ``return`` statement can only be used without a |
| 483 | value, and signals the end of the procession of values; after executing a |
| 484 | ``return`` the generator cannot return any further values. ``return`` with a |
| 485 | value, such as ``return 5``, is a syntax error inside a generator function. The |
| 486 | end of the generator's results can also be indicated by raising |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 487 | :exc:`StopIteration` manually, or by just letting the flow of execution fall off |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 488 | the bottom of the function. |
| 489 | |
| 490 | You could achieve the effect of generators manually by writing your own class |
| 491 | and storing all the local variables of the generator as instance variables. For |
| 492 | example, returning a list of integers could be done by setting ``self.count`` to |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 493 | 0, and having the :meth:`~iterator.__next__` method increment ``self.count`` and |
| 494 | return it. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 495 | However, for a moderately complicated generator, writing a corresponding class |
| 496 | can be much messier. |
| 497 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 498 | The test suite included with Python's library, |
| 499 | :source:`Lib/test/test_generators.py`, contains |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 500 | a number of more interesting examples. Here's one generator that implements an |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 501 | in-order traversal of a tree using generators recursively. :: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 502 | |
| 503 | # A recursive generator that generates Tree leaves in in-order. |
| 504 | def inorder(t): |
| 505 | if t: |
| 506 | for x in inorder(t.left): |
| 507 | yield x |
| 508 | |
| 509 | yield t.label |
| 510 | |
| 511 | for x in inorder(t.right): |
| 512 | yield x |
| 513 | |
| 514 | Two other examples in ``test_generators.py`` produce solutions for the N-Queens |
| 515 | problem (placing N queens on an NxN chess board so that no queen threatens |
| 516 | another) and the Knight's Tour (finding a route that takes a knight to every |
| 517 | square of an NxN chessboard without visiting any square twice). |
| 518 | |
| 519 | |
| 520 | |
| 521 | Passing values into a generator |
| 522 | ------------------------------- |
| 523 | |
| 524 | In Python 2.4 and earlier, generators only produced output. Once a generator's |
| 525 | code was invoked to create an iterator, there was no way to pass any new |
| 526 | information into the function when its execution is resumed. You could hack |
| 527 | together this ability by making the generator look at a global variable or by |
| 528 | passing in some mutable object that callers then modify, but these approaches |
| 529 | are messy. |
| 530 | |
| 531 | In Python 2.5 there's a simple way to pass values into a generator. |
| 532 | :keyword:`yield` became an expression, returning a value that can be assigned to |
| 533 | a variable or otherwise operated on:: |
| 534 | |
| 535 | val = (yield i) |
| 536 | |
| 537 | I recommend that you **always** put parentheses around a ``yield`` expression |
| 538 | when you're doing something with the returned value, as in the above example. |
| 539 | The parentheses aren't always necessary, but it's easier to always add them |
| 540 | instead of having to remember when they're needed. |
| 541 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 542 | (:pep:`342` explains the exact rules, which are that a ``yield``-expression must |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 543 | always be parenthesized except when it occurs at the top-level expression on the |
| 544 | right-hand side of an assignment. This means you can write ``val = yield i`` |
| 545 | but have to use parentheses when there's an operation, as in ``val = (yield i) |
| 546 | + 12``.) |
| 547 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 548 | Values are sent into a generator by calling its :meth:`send(value) |
| 549 | <generator.send>` method. This method resumes the generator's code and the |
| 550 | ``yield`` expression returns the specified value. If the regular |
| 551 | :meth:`~generator.__next__` method is called, the ``yield`` returns ``None``. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 552 | |
| 553 | Here's a simple counter that increments by 1 and allows changing the value of |
| 554 | the internal counter. |
| 555 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 556 | .. testcode:: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 557 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 558 | def counter(maximum): |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 559 | i = 0 |
| 560 | while i < maximum: |
| 561 | val = (yield i) |
| 562 | # If value provided, change counter |
| 563 | if val is not None: |
| 564 | i = val |
| 565 | else: |
| 566 | i += 1 |
| 567 | |
| 568 | And here's an example of changing the counter: |
| 569 | |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 570 | >>> it = counter(10) #doctest: +SKIP |
| 571 | >>> next(it) #doctest: +SKIP |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 572 | 0 |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 573 | >>> next(it) #doctest: +SKIP |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 574 | 1 |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 575 | >>> it.send(8) #doctest: +SKIP |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 576 | 8 |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 577 | >>> next(it) #doctest: +SKIP |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 578 | 9 |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 579 | >>> next(it) #doctest: +SKIP |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 580 | Traceback (most recent call last): |
Georg Brandl | 1f01deb | 2009-01-03 22:47:39 +0000 | [diff] [blame] | 581 | File "t.py", line 15, in ? |
Georg Brandl | 6911e3c | 2007-09-04 07:15:32 +0000 | [diff] [blame] | 582 | it.next() |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 583 | StopIteration |
| 584 | |
| 585 | Because ``yield`` will often be returning ``None``, you should always check for |
| 586 | this case. Don't just use its value in expressions unless you're sure that the |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 587 | :meth:`~generator.send` method will be the only method used resume your |
| 588 | generator function. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 589 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 590 | In addition to :meth:`~generator.send`, there are two other methods on |
| 591 | generators: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 592 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 593 | * :meth:`throw(type, value=None, traceback=None) <generator.throw>` is used to |
| 594 | raise an exception inside the generator; the exception is raised by the |
| 595 | ``yield`` expression where the generator's execution is paused. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 596 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 597 | * :meth:`~generator.close` raises a :exc:`GeneratorExit` exception inside the |
| 598 | generator to terminate the iteration. On receiving this exception, the |
| 599 | generator's code must either raise :exc:`GeneratorExit` or |
| 600 | :exc:`StopIteration`; catching the exception and doing anything else is |
| 601 | illegal and will trigger a :exc:`RuntimeError`. :meth:`~generator.close` |
| 602 | will also be called by Python's garbage collector when the generator is |
| 603 | garbage-collected. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 604 | |
| 605 | If you need to run cleanup code when a :exc:`GeneratorExit` occurs, I suggest |
| 606 | using a ``try: ... finally:`` suite instead of catching :exc:`GeneratorExit`. |
| 607 | |
| 608 | The cumulative effect of these changes is to turn generators from one-way |
| 609 | producers of information into both producers and consumers. |
| 610 | |
| 611 | Generators also become **coroutines**, a more generalized form of subroutines. |
| 612 | Subroutines are entered at one point and exited at another point (the top of the |
| 613 | function, and a ``return`` statement), but coroutines can be entered, exited, |
| 614 | and resumed at many different points (the ``yield`` statements). |
| 615 | |
| 616 | |
| 617 | Built-in functions |
| 618 | ================== |
| 619 | |
| 620 | Let's look in more detail at built-in functions often used with iterators. |
| 621 | |
Georg Brandl | f694518 | 2008-02-01 11:56:49 +0000 | [diff] [blame] | 622 | Two of Python's built-in functions, :func:`map` and :func:`filter` duplicate the |
| 623 | features of generator expressions: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 624 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 625 | :func:`map(f, iterA, iterB, ...) <map>` returns an iterator over the sequence |
Georg Brandl | f694518 | 2008-02-01 11:56:49 +0000 | [diff] [blame] | 626 | ``f(iterA[0], iterB[0]), f(iterA[1], iterB[1]), f(iterA[2], iterB[2]), ...``. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 627 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 628 | >>> def upper(s): |
| 629 | ... return s.upper() |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 630 | |
Georg Brandl | a3deea1 | 2008-12-15 08:29:32 +0000 | [diff] [blame] | 631 | >>> list(map(upper, ['sentence', 'fragment'])) |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 632 | ['SENTENCE', 'FRAGMENT'] |
| 633 | >>> [upper(s) for s in ['sentence', 'fragment']] |
| 634 | ['SENTENCE', 'FRAGMENT'] |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 635 | |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 636 | You can of course achieve the same effect with a list comprehension. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 637 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 638 | :func:`filter(predicate, iter) <filter>` returns an iterator over all the |
| 639 | sequence elements that meet a certain condition, and is similarly duplicated by |
| 640 | list comprehensions. A **predicate** is a function that returns the truth |
| 641 | value of some condition; for use with :func:`filter`, the predicate must take a |
| 642 | single value. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 643 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 644 | >>> def is_even(x): |
| 645 | ... return (x % 2) == 0 |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 646 | |
Georg Brandl | a3deea1 | 2008-12-15 08:29:32 +0000 | [diff] [blame] | 647 | >>> list(filter(is_even, range(10))) |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 648 | [0, 2, 4, 6, 8] |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 649 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 650 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 651 | This can also be written as a list comprehension: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 652 | |
Georg Brandl | f694518 | 2008-02-01 11:56:49 +0000 | [diff] [blame] | 653 | >>> list(x for x in range(10) if is_even(x)) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 654 | [0, 2, 4, 6, 8] |
| 655 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 656 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 657 | :func:`enumerate(iter) <enumerate>` counts off the elements in the iterable, |
| 658 | returning 2-tuples containing the count and each element. :: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 659 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 660 | >>> for item in enumerate(['subject', 'verb', 'object']): |
Neal Norwitz | 752abd0 | 2008-05-13 04:55:24 +0000 | [diff] [blame] | 661 | ... print(item) |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 662 | (0, 'subject') |
| 663 | (1, 'verb') |
| 664 | (2, 'object') |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 665 | |
| 666 | :func:`enumerate` is often used when looping through a list and recording the |
| 667 | indexes at which certain conditions are met:: |
| 668 | |
| 669 | f = open('data.txt', 'r') |
| 670 | for i, line in enumerate(f): |
| 671 | if line.strip() == '': |
Georg Brandl | 6911e3c | 2007-09-04 07:15:32 +0000 | [diff] [blame] | 672 | print('Blank line at line #%i' % i) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 673 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 674 | :func:`sorted(iterable, key=None, reverse=False) <sorted>` collects all the |
| 675 | elements of the iterable into a list, sorts the list, and returns the sorted |
| 676 | result. The *key*, and *reverse* arguments are passed through to the |
| 677 | constructed list's :meth:`~list.sort` method. :: |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 678 | |
| 679 | >>> import random |
| 680 | >>> # Generate 8 random numbers between [0, 10000) |
| 681 | >>> rand_list = random.sample(range(10000), 8) |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 682 | >>> rand_list #doctest: +SKIP |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 683 | [769, 7953, 9828, 6431, 8442, 9878, 6213, 2207] |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 684 | >>> sorted(rand_list) #doctest: +SKIP |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 685 | [769, 2207, 6213, 6431, 7953, 8442, 9828, 9878] |
Ezio Melotti | 35cbf16 | 2012-10-12 13:24:19 +0300 | [diff] [blame] | 686 | >>> sorted(rand_list, reverse=True) #doctest: +SKIP |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 687 | [9878, 9828, 8442, 7953, 6431, 6213, 2207, 769] |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 688 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 689 | (For a more detailed discussion of sorting, see the :ref:`sortinghowto`.) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 690 | |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 691 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 692 | The :func:`any(iter) <any>` and :func:`all(iter) <all>` built-ins look at the |
| 693 | truth values of an iterable's contents. :func:`any` returns True if any element |
| 694 | in the iterable is a true value, and :func:`all` returns True if all of the |
| 695 | elements are true values: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 696 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 697 | >>> any([0,1,0]) |
| 698 | True |
| 699 | >>> any([0,0,0]) |
| 700 | False |
| 701 | >>> any([1,1,1]) |
| 702 | True |
| 703 | >>> all([0,1,0]) |
| 704 | False |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 705 | >>> all([0,0,0]) |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 706 | False |
| 707 | >>> all([1,1,1]) |
| 708 | True |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 709 | |
| 710 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 711 | :func:`zip(iterA, iterB, ...) <zip>` takes one element from each iterable and |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 712 | returns them in a tuple:: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 713 | |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 714 | zip(['a', 'b', 'c'], (1, 2, 3)) => |
| 715 | ('a', 1), ('b', 2), ('c', 3) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 716 | |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 717 | It doesn't construct an in-memory list and exhaust all the input iterators |
| 718 | before returning; instead tuples are constructed and returned only if they're |
| 719 | requested. (The technical term for this behaviour is `lazy evaluation |
| 720 | <http://en.wikipedia.org/wiki/Lazy_evaluation>`__.) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 721 | |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 722 | This iterator is intended to be used with iterables that are all of the same |
| 723 | length. If the iterables are of different lengths, the resulting stream will be |
| 724 | the same length as the shortest iterable. :: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 725 | |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 726 | zip(['a', 'b'], (1, 2, 3)) => |
| 727 | ('a', 1), ('b', 2) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 728 | |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 729 | You should avoid doing this, though, because an element may be taken from the |
| 730 | longer iterators and discarded. This means you can't go on to use the iterators |
| 731 | further because you risk skipping a discarded element. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 732 | |
| 733 | |
| 734 | The itertools module |
| 735 | ==================== |
| 736 | |
| 737 | The :mod:`itertools` module contains a number of commonly-used iterators as well |
| 738 | as functions for combining several iterators. This section will introduce the |
| 739 | module's contents by showing small examples. |
| 740 | |
| 741 | The module's functions fall into a few broad classes: |
| 742 | |
| 743 | * Functions that create a new iterator based on an existing iterator. |
| 744 | * Functions for treating an iterator's elements as function arguments. |
| 745 | * Functions for selecting portions of an iterator's output. |
| 746 | * A function for grouping an iterator's output. |
| 747 | |
| 748 | Creating new iterators |
| 749 | ---------------------- |
| 750 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 751 | :func:`itertools.count(n) <itertools.count>` returns an infinite stream of |
| 752 | integers, increasing by 1 each time. You can optionally supply the starting |
| 753 | number, which defaults to 0:: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 754 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 755 | itertools.count() => |
| 756 | 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ... |
| 757 | itertools.count(10) => |
| 758 | 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 759 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 760 | :func:`itertools.cycle(iter) <itertools.cycle>` saves a copy of the contents of |
| 761 | a provided iterable and returns a new iterator that returns its elements from |
| 762 | first to last. The new iterator will repeat these elements infinitely. :: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 763 | |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 764 | itertools.cycle([1,2,3,4,5]) => |
| 765 | 1, 2, 3, 4, 5, 1, 2, 3, 4, 5, ... |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 766 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 767 | :func:`itertools.repeat(elem, [n]) <itertools.repeat>` returns the provided |
| 768 | element *n* times, or returns the element endlessly if *n* is not provided. :: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 769 | |
| 770 | itertools.repeat('abc') => |
| 771 | abc, abc, abc, abc, abc, abc, abc, abc, abc, abc, ... |
| 772 | itertools.repeat('abc', 5) => |
| 773 | abc, abc, abc, abc, abc |
| 774 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 775 | :func:`itertools.chain(iterA, iterB, ...) <itertools.chain>` takes an arbitrary |
| 776 | number of iterables as input, and returns all the elements of the first |
| 777 | iterator, then all the elements of the second, and so on, until all of the |
| 778 | iterables have been exhausted. :: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 779 | |
| 780 | itertools.chain(['a', 'b', 'c'], (1, 2, 3)) => |
| 781 | a, b, c, 1, 2, 3 |
| 782 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 783 | :func:`itertools.islice(iter, [start], stop, [step]) <itertools.islice>` returns |
| 784 | a stream that's a slice of the iterator. With a single *stop* argument, it |
| 785 | will return the first *stop* elements. If you supply a starting index, you'll |
| 786 | get *stop-start* elements, and if you supply a value for *step*, elements |
| 787 | will be skipped accordingly. Unlike Python's string and list slicing, you can't |
| 788 | use negative values for *start*, *stop*, or *step*. :: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 789 | |
| 790 | itertools.islice(range(10), 8) => |
| 791 | 0, 1, 2, 3, 4, 5, 6, 7 |
| 792 | itertools.islice(range(10), 2, 8) => |
| 793 | 2, 3, 4, 5, 6, 7 |
| 794 | itertools.islice(range(10), 2, 8, 2) => |
| 795 | 2, 4, 6 |
| 796 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 797 | :func:`itertools.tee(iter, [n]) <itertools.tee>` replicates an iterator; it |
| 798 | returns *n* independent iterators that will all return the contents of the |
| 799 | source iterator. |
| 800 | If you don't supply a value for *n*, the default is 2. Replicating iterators |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 801 | requires saving some of the contents of the source iterator, so this can consume |
| 802 | significant memory if the iterator is large and one of the new iterators is |
Christian Heimes | fe337bf | 2008-03-23 21:54:12 +0000 | [diff] [blame] | 803 | consumed more than the others. :: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 804 | |
| 805 | itertools.tee( itertools.count() ) => |
| 806 | iterA, iterB |
| 807 | |
| 808 | where iterA -> |
| 809 | 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ... |
| 810 | |
| 811 | and iterB -> |
| 812 | 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ... |
| 813 | |
| 814 | |
| 815 | Calling functions on elements |
| 816 | ----------------------------- |
| 817 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 818 | The :mod:`operator` module contains a set of functions corresponding to Python's |
| 819 | operators. Some examples are :func:`operator.add(a, b) <operator.add>` (adds |
| 820 | two values), :func:`operator.ne(a, b) <operator.ne>` (same as ``a != b``), and |
| 821 | :func:`operator.attrgetter('id') <operator.attrgetter>` |
| 822 | (returns a callable that fetches the ``.id`` attribute). |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 823 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 824 | :func:`itertools.starmap(func, iter) <itertools.starmap>` assumes that the |
| 825 | iterable will return a stream of tuples, and calls *func* using these tuples as |
| 826 | the arguments:: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 827 | |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 828 | itertools.starmap(os.path.join, |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 829 | [('/bin', 'python'), ('/usr', 'bin', 'java'), |
| 830 | ('/usr', 'bin', 'perl'), ('/usr', 'bin', 'ruby')]) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 831 | => |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 832 | /bin/python, /usr/bin/java, /usr/bin/perl, /usr/bin/ruby |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 833 | |
| 834 | |
| 835 | Selecting elements |
| 836 | ------------------ |
| 837 | |
| 838 | Another group of functions chooses a subset of an iterator's elements based on a |
| 839 | predicate. |
| 840 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 841 | :func:`itertools.filterfalse(predicate, iter) <itertools.filterfalse>` is the |
| 842 | opposite, returning all elements for which the predicate returns false:: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 843 | |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 844 | itertools.filterfalse(is_even, itertools.count()) => |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 845 | 1, 3, 5, 7, 9, 11, 13, 15, ... |
| 846 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 847 | :func:`itertools.takewhile(predicate, iter) <itertools.takewhile>` returns |
| 848 | elements for as long as the predicate returns true. Once the predicate returns |
| 849 | false, the iterator will signal the end of its results. :: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 850 | |
| 851 | def less_than_10(x): |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 852 | return x < 10 |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 853 | |
| 854 | itertools.takewhile(less_than_10, itertools.count()) => |
| 855 | 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 |
| 856 | |
| 857 | itertools.takewhile(is_even, itertools.count()) => |
| 858 | 0 |
| 859 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 860 | :func:`itertools.dropwhile(predicate, iter) <itertools.dropwhile>` discards |
| 861 | elements while the predicate returns true, and then returns the rest of the |
| 862 | iterable's results. :: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 863 | |
| 864 | itertools.dropwhile(less_than_10, itertools.count()) => |
| 865 | 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... |
| 866 | |
| 867 | itertools.dropwhile(is_even, itertools.count()) => |
| 868 | 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ... |
| 869 | |
| 870 | |
| 871 | Grouping elements |
| 872 | ----------------- |
| 873 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 874 | The last function I'll discuss, :func:`itertools.groupby(iter, key_func=None) |
| 875 | <itertools.groupby>`, is the most complicated. ``key_func(elem)`` is a function |
| 876 | that can compute a key value for each element returned by the iterable. If you |
| 877 | don't supply a key function, the key is simply each element itself. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 878 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 879 | :func:`~itertools.groupby` collects all the consecutive elements from the |
| 880 | underlying iterable that have the same key value, and returns a stream of |
| 881 | 2-tuples containing a key value and an iterator for the elements with that key. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 882 | |
| 883 | :: |
| 884 | |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 885 | city_list = [('Decatur', 'AL'), ('Huntsville', 'AL'), ('Selma', 'AL'), |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 886 | ('Anchorage', 'AK'), ('Nome', 'AK'), |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 887 | ('Flagstaff', 'AZ'), ('Phoenix', 'AZ'), ('Tucson', 'AZ'), |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 888 | ... |
| 889 | ] |
| 890 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 891 | def get_state(city_state): |
Georg Brandl | 0df7979 | 2008-10-04 18:33:26 +0000 | [diff] [blame] | 892 | return city_state[1] |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 893 | |
| 894 | itertools.groupby(city_list, get_state) => |
| 895 | ('AL', iterator-1), |
| 896 | ('AK', iterator-2), |
| 897 | ('AZ', iterator-3), ... |
| 898 | |
| 899 | where |
| 900 | iterator-1 => |
| 901 | ('Decatur', 'AL'), ('Huntsville', 'AL'), ('Selma', 'AL') |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 902 | iterator-2 => |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 903 | ('Anchorage', 'AK'), ('Nome', 'AK') |
| 904 | iterator-3 => |
| 905 | ('Flagstaff', 'AZ'), ('Phoenix', 'AZ'), ('Tucson', 'AZ') |
| 906 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 907 | :func:`~itertools.groupby` assumes that the underlying iterable's contents will |
| 908 | already be sorted based on the key. Note that the returned iterators also use |
| 909 | the underlying iterable, so you have to consume the results of iterator-1 before |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 910 | requesting iterator-2 and its corresponding key. |
| 911 | |
| 912 | |
| 913 | The functools module |
| 914 | ==================== |
| 915 | |
| 916 | The :mod:`functools` module in Python 2.5 contains some higher-order functions. |
| 917 | A **higher-order function** takes one or more functions as input and returns a |
| 918 | new function. The most useful tool in this module is the |
| 919 | :func:`functools.partial` function. |
| 920 | |
| 921 | For programs written in a functional style, you'll sometimes want to construct |
| 922 | variants of existing functions that have some of the parameters filled in. |
| 923 | Consider a Python function ``f(a, b, c)``; you may wish to create a new function |
| 924 | ``g(b, c)`` that's equivalent to ``f(1, b, c)``; you're filling in a value for |
| 925 | one of ``f()``'s parameters. This is called "partial function application". |
| 926 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 927 | The constructor for :func:`~functools.partial` takes the arguments |
| 928 | ``(function, arg1, arg2, ..., kwarg1=value1, kwarg2=value2)``. The resulting |
| 929 | object is callable, so you can just call it to invoke ``function`` with the |
| 930 | filled-in arguments. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 931 | |
| 932 | Here's a small but realistic example:: |
| 933 | |
| 934 | import functools |
| 935 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 936 | def log(message, subsystem): |
| 937 | """Write the contents of 'message' to the specified subsystem.""" |
Georg Brandl | 6911e3c | 2007-09-04 07:15:32 +0000 | [diff] [blame] | 938 | print('%s: %s' % (subsystem, message)) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 939 | ... |
| 940 | |
| 941 | server_log = functools.partial(log, subsystem='server') |
| 942 | server_log('Unable to open socket') |
| 943 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 944 | :func:`functools.reduce(func, iter, [initial_value]) <functools.reduce>` |
| 945 | cumulatively performs an operation on all the iterable's elements and, |
| 946 | therefore, can't be applied to infinite iterables. *func* must be a function |
| 947 | that takes two elements and returns a single value. :func:`functools.reduce` |
| 948 | takes the first two elements A and B returned by the iterator and calculates |
| 949 | ``func(A, B)``. It then requests the third element, C, calculates |
| 950 | ``func(func(A, B), C)``, combines this result with the fourth element returned, |
| 951 | and continues until the iterable is exhausted. If the iterable returns no |
| 952 | values at all, a :exc:`TypeError` exception is raised. If the initial value is |
| 953 | supplied, it's used as a starting point and ``func(initial_value, A)`` is the |
| 954 | first calculation. :: |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 955 | |
| 956 | >>> import operator, functools |
| 957 | >>> functools.reduce(operator.concat, ['A', 'BB', 'C']) |
| 958 | 'ABBC' |
| 959 | >>> functools.reduce(operator.concat, []) |
| 960 | Traceback (most recent call last): |
| 961 | ... |
| 962 | TypeError: reduce() of empty sequence with no initial value |
| 963 | >>> functools.reduce(operator.mul, [1,2,3], 1) |
| 964 | 6 |
| 965 | >>> functools.reduce(operator.mul, [], 1) |
| 966 | 1 |
| 967 | |
| 968 | If you use :func:`operator.add` with :func:`functools.reduce`, you'll add up all the |
| 969 | elements of the iterable. This case is so common that there's a special |
| 970 | built-in called :func:`sum` to compute it: |
| 971 | |
| 972 | >>> import functools |
| 973 | >>> functools.reduce(operator.add, [1,2,3,4], 0) |
| 974 | 10 |
| 975 | >>> sum([1,2,3,4]) |
| 976 | 10 |
| 977 | >>> sum([]) |
| 978 | 0 |
| 979 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 980 | For many uses of :func:`functools.reduce`, though, it can be clearer to just |
| 981 | write the obvious :keyword:`for` loop:: |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 982 | |
| 983 | import functools |
| 984 | # Instead of: |
| 985 | product = functools.reduce(operator.mul, [1,2,3], 1) |
| 986 | |
| 987 | # You can write: |
| 988 | product = 1 |
| 989 | for i in [1,2,3]: |
| 990 | product *= i |
| 991 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 992 | |
| 993 | The operator module |
| 994 | ------------------- |
| 995 | |
| 996 | The :mod:`operator` module was mentioned earlier. It contains a set of |
| 997 | functions corresponding to Python's operators. These functions are often useful |
| 998 | in functional-style code because they save you from writing trivial functions |
| 999 | that perform a single operation. |
| 1000 | |
| 1001 | Some of the functions in this module are: |
| 1002 | |
Georg Brandl | f694518 | 2008-02-01 11:56:49 +0000 | [diff] [blame] | 1003 | * Math operations: ``add()``, ``sub()``, ``mul()``, ``floordiv()``, ``abs()``, ... |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 1004 | * Logical operations: ``not_()``, ``truth()``. |
| 1005 | * Bitwise operations: ``and_()``, ``or_()``, ``invert()``. |
| 1006 | * Comparisons: ``eq()``, ``ne()``, ``lt()``, ``le()``, ``gt()``, and ``ge()``. |
| 1007 | * Object identity: ``is_()``, ``is_not()``. |
| 1008 | |
| 1009 | Consult the operator module's documentation for a complete list. |
| 1010 | |
| 1011 | |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 1012 | Small functions and the lambda expression |
| 1013 | ========================================= |
| 1014 | |
| 1015 | When writing functional-style programs, you'll often need little functions that |
| 1016 | act as predicates or that combine elements in some way. |
| 1017 | |
| 1018 | If there's a Python built-in or a module function that's suitable, you don't |
| 1019 | need to define a new function at all:: |
| 1020 | |
| 1021 | stripped_lines = [line.strip() for line in lines] |
| 1022 | existing_files = filter(os.path.exists, file_list) |
| 1023 | |
| 1024 | If the function you need doesn't exist, you need to write it. One way to write |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 1025 | small functions is to use the :keyword:`lambda` statement. ``lambda`` takes a |
| 1026 | number of parameters and an expression combining these parameters, and creates |
| 1027 | an anonymous function that returns the value of the expression:: |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 1028 | |
| 1029 | adder = lambda x, y: x+y |
| 1030 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 1031 | print_assign = lambda name, value: name + '=' + str(value) |
| 1032 | |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 1033 | An alternative is to just use the ``def`` statement and define a function in the |
| 1034 | usual way:: |
| 1035 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 1036 | def adder(x, y): |
| 1037 | return x + y |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 1038 | |
| 1039 | def print_assign(name, value): |
| 1040 | return name + '=' + str(value) |
| 1041 | |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 1042 | Which alternative is preferable? That's a style question; my usual course is to |
| 1043 | avoid using ``lambda``. |
| 1044 | |
| 1045 | One reason for my preference is that ``lambda`` is quite limited in the |
| 1046 | functions it can define. The result has to be computable as a single |
| 1047 | expression, which means you can't have multiway ``if... elif... else`` |
| 1048 | comparisons or ``try... except`` statements. If you try to do too much in a |
| 1049 | ``lambda`` statement, you'll end up with an overly complicated expression that's |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 1050 | hard to read. Quick, what's the following code doing? :: |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 1051 | |
| 1052 | import functools |
| 1053 | total = functools.reduce(lambda a, b: (0, a[1] + b[1]), items)[1] |
| 1054 | |
| 1055 | You can figure it out, but it takes time to disentangle the expression to figure |
| 1056 | out what's going on. Using a short nested ``def`` statements makes things a |
| 1057 | little bit better:: |
| 1058 | |
| 1059 | import functools |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 1060 | def combine(a, b): |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 1061 | return 0, a[1] + b[1] |
| 1062 | |
| 1063 | total = functools.reduce(combine, items)[1] |
| 1064 | |
| 1065 | But it would be best of all if I had simply used a ``for`` loop:: |
| 1066 | |
| 1067 | total = 0 |
| 1068 | for a, b in items: |
| 1069 | total += b |
| 1070 | |
| 1071 | Or the :func:`sum` built-in and a generator expression:: |
| 1072 | |
| 1073 | total = sum(b for a,b in items) |
| 1074 | |
| 1075 | Many uses of :func:`functools.reduce` are clearer when written as ``for`` loops. |
| 1076 | |
| 1077 | Fredrik Lundh once suggested the following set of rules for refactoring uses of |
| 1078 | ``lambda``: |
| 1079 | |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 1080 | 1. Write a lambda function. |
| 1081 | 2. Write a comment explaining what the heck that lambda does. |
| 1082 | 3. Study the comment for a while, and think of a name that captures the essence |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 1083 | of the comment. |
Ezio Melotti | 45a101d | 2012-10-12 12:42:51 +0300 | [diff] [blame] | 1084 | 4. Convert the lambda to a def statement, using that name. |
| 1085 | 5. Remove the comment. |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 1086 | |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 1087 | I really like these rules, but you're free to disagree |
Georg Brandl | 4216d2d | 2008-11-22 08:27:24 +0000 | [diff] [blame] | 1088 | about whether this lambda-free style is better. |
| 1089 | |
| 1090 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 1091 | Revision History and Acknowledgements |
| 1092 | ===================================== |
| 1093 | |
| 1094 | The author would like to thank the following people for offering suggestions, |
| 1095 | corrections and assistance with various drafts of this article: Ian Bicking, |
| 1096 | Nick Coghlan, Nick Efford, Raymond Hettinger, Jim Jewett, Mike Krell, Leandro |
| 1097 | Lameiro, Jussi Salmela, Collin Winter, Blake Winton. |
| 1098 | |
| 1099 | Version 0.1: posted June 30 2006. |
| 1100 | |
| 1101 | Version 0.11: posted July 1 2006. Typo fixes. |
| 1102 | |
| 1103 | Version 0.2: posted July 10 2006. Merged genexp and listcomp sections into one. |
| 1104 | Typo fixes. |
| 1105 | |
| 1106 | Version 0.21: Added more references suggested on the tutor mailing list. |
| 1107 | |
| 1108 | Version 0.30: Adds a section on the ``functional`` module written by Collin |
| 1109 | Winter; adds short section on the operator module; a few other edits. |
| 1110 | |
| 1111 | |
| 1112 | References |
| 1113 | ========== |
| 1114 | |
| 1115 | General |
| 1116 | ------- |
| 1117 | |
| 1118 | **Structure and Interpretation of Computer Programs**, by Harold Abelson and |
| 1119 | Gerald Jay Sussman with Julie Sussman. Full text at |
| 1120 | http://mitpress.mit.edu/sicp/. In this classic textbook of computer science, |
| 1121 | chapters 2 and 3 discuss the use of sequences and streams to organize the data |
| 1122 | flow inside a program. The book uses Scheme for its examples, but many of the |
| 1123 | design approaches described in these chapters are applicable to functional-style |
| 1124 | Python code. |
| 1125 | |
| 1126 | http://www.defmacro.org/ramblings/fp.html: A general introduction to functional |
| 1127 | programming that uses Java examples and has a lengthy historical introduction. |
| 1128 | |
| 1129 | http://en.wikipedia.org/wiki/Functional_programming: General Wikipedia entry |
| 1130 | describing functional programming. |
| 1131 | |
| 1132 | http://en.wikipedia.org/wiki/Coroutine: Entry for coroutines. |
| 1133 | |
| 1134 | http://en.wikipedia.org/wiki/Currying: Entry for the concept of currying. |
| 1135 | |
| 1136 | Python-specific |
| 1137 | --------------- |
| 1138 | |
| 1139 | http://gnosis.cx/TPiP/: The first chapter of David Mertz's book |
| 1140 | :title-reference:`Text Processing in Python` discusses functional programming |
| 1141 | for text processing, in the section titled "Utilizing Higher-Order Functions in |
| 1142 | Text Processing". |
| 1143 | |
| 1144 | Mertz also wrote a 3-part series of articles on functional programming |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 1145 | for IBM's DeveloperWorks site; see |
Sandro Tosi | 1abde36 | 2011-12-31 18:46:50 +0100 | [diff] [blame] | 1146 | `part 1 <http://www.ibm.com/developerworks/linux/library/l-prog/index.html>`__, |
| 1147 | `part 2 <http://www.ibm.com/developerworks/linux/library/l-prog2/index.html>`__, and |
| 1148 | `part 3 <http://www.ibm.com/developerworks/linux/library/l-prog3/index.html>`__, |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 1149 | |
| 1150 | |
| 1151 | Python documentation |
| 1152 | -------------------- |
| 1153 | |
| 1154 | Documentation for the :mod:`itertools` module. |
| 1155 | |
| 1156 | Documentation for the :mod:`operator` module. |
| 1157 | |
| 1158 | :pep:`289`: "Generator Expressions" |
| 1159 | |
| 1160 | :pep:`342`: "Coroutines via Enhanced Generators" describes the new generator |
| 1161 | features in Python 2.5. |
| 1162 | |
| 1163 | .. comment |
| 1164 | |
| 1165 | Topics to place |
| 1166 | ----------------------------- |
| 1167 | |
| 1168 | XXX os.walk() |
| 1169 | |
| 1170 | XXX Need a large example. |
| 1171 | |
| 1172 | But will an example add much? I'll post a first draft and see |
| 1173 | what the comments say. |
| 1174 | |
| 1175 | .. comment |
| 1176 | |
| 1177 | Original outline: |
| 1178 | Introduction |
| 1179 | Idea of FP |
| 1180 | Programs built out of functions |
| 1181 | Functions are strictly input-output, no internal state |
| 1182 | Opposed to OO programming, where objects have state |
| 1183 | |
| 1184 | Why FP? |
| 1185 | Formal provability |
| 1186 | Assignment is difficult to reason about |
| 1187 | Not very relevant to Python |
| 1188 | Modularity |
| 1189 | Small functions that do one thing |
| 1190 | Debuggability: |
| 1191 | Easy to test due to lack of state |
| 1192 | Easy to verify output from intermediate steps |
| 1193 | Composability |
| 1194 | You assemble a toolbox of functions that can be mixed |
| 1195 | |
| 1196 | Tackling a problem |
| 1197 | Need a significant example |
| 1198 | |
| 1199 | Iterators |
| 1200 | Generators |
| 1201 | The itertools module |
| 1202 | List comprehensions |
| 1203 | Small functions and the lambda statement |
| 1204 | Built-in functions |
| 1205 | map |
| 1206 | filter |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 1207 | |
| 1208 | .. comment |
| 1209 | |
| 1210 | Handy little function for printing part of an iterator -- used |
| 1211 | while writing this document. |
| 1212 | |
| 1213 | import itertools |
| 1214 | def print_iter(it): |
| 1215 | slice = itertools.islice(it, 10) |
| 1216 | for elem in slice[:-1]: |
| 1217 | sys.stdout.write(str(elem)) |
| 1218 | sys.stdout.write(', ') |
Georg Brandl | 6911e3c | 2007-09-04 07:15:32 +0000 | [diff] [blame] | 1219 | print(elem[-1]) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 1220 | |
| 1221 | |