@@ -111,7 +111,8 @@ \section{Unicode}
111111\item \var {encode_func} is a function that takes a Unicode string, and
112112returns a 2-tuple \code {(\var {string}, \var {length})}. \var {string}
113113is an 8-bit string containing a portion (perhaps all) of the Unicode
114- string converted into the given encoding, and \var {length} tells you how much of the Unicode string was converted.
114+ string converted into the given encoding, and \var {length} tells you
115+ how much of the Unicode string was converted.
115116
116117\item \var {decode_func} is the mirror of \var {encode_func},
117118taking a Unicode string and
@@ -165,6 +166,121 @@ \section{Unicode}
165166code, since some future version of Python may drop support for 8-bit
166167strings and provide only Unicode strings.
167168
169+ % ======================================================================
170+ \section {List Comprehensions }
171+
172+ Lists are a workhorse data type in Python, and many programs
173+ manipulate a list at some point. Two common operations on lists are
174+ to loop over them, and either pick out the elements that meet a
175+ certain criterion, or apply some function to each element. For
176+ example, given a list of strings, you might want to pull out all the
177+ strings containing a given substring, or strip off trailing whitespace
178+ from each line.
179+
180+ The existing \function {map()} and \function {filter()} functions can be
181+ used for this purpose, but they require a function as one of their
182+ arguments. This is fine if there's an existing built-in function that
183+ can be passed directly, but if there isn't, you have to create a
184+ little function to do the required work, and Python's scoping rules
185+ make the result ugly if the little function needs additional
186+ information. Take the first example in the previous paragraph,
187+ finding all the strings in the list containing a given substring. You
188+ could write the following to do it:
189+
190+ \begin {verbatim }
191+ # Given the list L, make a list of all strings
192+ # containing the substring S.
193+ sublist = filter( lambda s, substring=S:
194+ string.find(s, substring) != -1,
195+ L)
196+ \end {verbatim }
197+
198+ Because of Python's scoping rules, a default argument is used so that
199+ the anonymous function created by the \keyword {lambda} statement knows
200+ what substring is being searched for. List comprehensions make this
201+ cleaner:
202+
203+ \begin {verbatim }
204+ sublist = [ s for s in L if string.find(s, S) != -1 ]
205+ \end {verbatim }
206+
207+ List comprehensions have the form:
208+
209+ \begin {verbatim }
210+ [ expression for expr in sequence1
211+ for expr2 in sequence2 ...
212+ for exprN in sequenceN
213+ if condition
214+ \end {verbatim }
215+
216+ The \keyword {for}...\keyword {in} clauses contain the sequences to be
217+ iterated over. The sequences do not have to be the same length,
218+ because they are \emph {not } iterated over in parallel, but
219+ from left to right; this is explained more clearly in the following
220+ paragraphs. The elements of the generated list will be the successive
221+ values of \var {expression}. The final \keyword {if} clause is
222+ optional; if present, \var {expression} is only evaluated and added to
223+ the result if \var {condition} is true.
224+
225+ To make the semantics very clear, a list comprehension is equivalent
226+ to the following Python code:
227+
228+ \begin {verbatim }
229+ for expr1 in sequence1:
230+ for expr2 in sequence2:
231+ ...
232+ for exprN in sequenceN:
233+ if (condition):
234+ # Append the value of
235+ # the expression to the
236+ # resulting list.
237+ \end {verbatim }
238+
239+ This means that when there are \keyword {for}...\keyword {in} clauses,
240+ the resulting list will be equal to the product of the lengths of all
241+ the sequences. If you have two lists of length 3, the output list is
242+ 9 elements long:
243+
244+ \begin {verbatim }
245+ seq1 = 'abc'
246+ seq2 = (1,2,3)
247+ >>> [ (x,y) for x in seq1 for y in seq2]
248+ [('a', 1), ('a', 2), ('a', 3), ('b', 1), ('b', 2), ('b', 3), ('c', 1),
249+ ('c', 2), ('c', 3)]
250+ \end {verbatim }
251+
252+ To avoid introducing an ambiguity into Python's grammar, if
253+ \var {expression} is creating a tuple, it must be surrounded with
254+ parentheses. The first list comprehension below is a syntax error,
255+ while the second one is correct:
256+
257+ \begin {verbatim }
258+ # Syntax error
259+ [ x,y for x in seq1 for y in seq2]
260+ # Correct
261+ [ (x,y) for x in seq1 for y in seq2]
262+ \end {verbatim }
263+
264+
265+ The idea of list comprehensions originally comes from the functional
266+ programming language Haskell (\url {http://www.haskell.org}). Greg
267+ Ewing argued most effectively for adding them to Python and wrote the
268+ initial list comprehension patch, which was then discussed for a
269+ seemingly endless time on the python-dev mailing list and kept
270+ up-to-date by Skip Montanaro.
271+
272+
273+
274+
275+ A list comprehension has the form [ e | q[1], ..., q[n] ], n>=1, where
276+ the q[i] qualifiers are either
277+ * generators of the form p <- e, where p is a pattern (see Section
278+ 3.17) of type t and e is an expression of type [t]
279+ * guards, which are arbitrary expressions of type Bool
280+ * local bindings that provide new definitions for use in the
281+ generated expression e or subsequent guards and generators.
282+
283+
168284% ======================================================================
169285\section {Distutils: Making Modules Easy to Install }
170286
@@ -353,9 +469,9 @@ \section{Optional Collection of Cycles}
353469
354470
355471% ======================================================================
356- \section {New XML Code }
472+ % \section{New XML Code}
357473
358- XXX write this section...
474+ % XXX write this section...
359475
360476% ======================================================================
361477\section {Porting to 2.0 }
@@ -612,7 +728,7 @@ \section{Extending/Embedding Changes}
612728Vladimir Marangozov's long-awaited malloc restructuring was completed,
613729to make it easy to have the Python interpreter use a custom allocator
614730instead of C's standard \function {malloc()}. For documentation, read
615- the comments in \file {Include/mymalloc .h} and
731+ the comments in \file {Include/pymem .h} and
616732\file {Include/objimpl.h}. For the lengthy discussions during which
617733the interface was hammered out, see the Web archives of the 'patches'
618734and 'python-dev' lists at python.org.
0 commit comments