mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-07-24 03:35:53 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 8

Merged revisions 59488-59511 via svnmerge from

Browse source 
svn+ssh://pythondev@svn.python.org/python/trunk

........
  r59489 | christian.heimes | 2007-12-14 03:33:57 +0100 (Fri, 14 Dec 2007) | 1 line

  Silence a warning about an unsed variable in debug builds
........
  r59490 | christian.heimes | 2007-12-14 03:35:23 +0100 (Fri, 14 Dec 2007) | 2 lines

  Fixed bug #1620: New @spam.getter property syntax modifies the property in place.
  I added also the feature that a @prop.getter decorator does not overwrite the doc string of the property if it was given as an argument to property().
........
  r59491 | raymond.hettinger | 2007-12-14 03:49:47 +0100 (Fri, 14 Dec 2007) | 1 line

  Cleaner method naming convention
........
  r59492 | christian.heimes | 2007-12-14 04:02:34 +0100 (Fri, 14 Dec 2007) | 1 line

  Fixed a warning in _codecs_iso2022.c and some non C89 conform // comments.
........
  r59493 | christian.heimes | 2007-12-14 05:38:13 +0100 (Fri, 14 Dec 2007) | 1 line

  Fixed warning in ssl module
........
  r59500 | raymond.hettinger | 2007-12-14 19:08:20 +0100 (Fri, 14 Dec 2007) | 1 line

  Add line spacing for readability
........
  r59501 | raymond.hettinger | 2007-12-14 19:12:21 +0100 (Fri, 14 Dec 2007) | 3 lines

  Update method names for named tuples.
........
  r59503 | georg.brandl | 2007-12-14 20:03:36 +0100 (Fri, 14 Dec 2007) | 3 lines

  Add a section about nested listcomps to the tutorial.
  Thanks to Ian Bruntlett and Robert Lehmann.
........
  r59504 | raymond.hettinger | 2007-12-14 20:19:59 +0100 (Fri, 14 Dec 2007) | 1 line

  Faster and simpler _replace() method
........
  r59505 | raymond.hettinger | 2007-12-14 22:51:50 +0100 (Fri, 14 Dec 2007) | 1 line

  Add usage note
........
  r59507 | andrew.kuchling | 2007-12-14 23:41:18 +0100 (Fri, 14 Dec 2007) | 1 line

  Remove warning about URL
........
  r59510 | andrew.kuchling | 2007-12-14 23:52:36 +0100 (Fri, 14 Dec 2007) | 1 line

  Bump the version number, and make a few small edits
........
  r59511 | christian.heimes | 2007-12-15 00:42:36 +0100 (Sat, 15 Dec 2007) | 2 lines

  Fixed bug #1628
  The detection now works on Unix with Makefile, Makefile with VPATH and on Windows.
........
This commit is contained in:
Christian Heimes 2007-12-15 01:27:15 +00:00
parent 54cc54c1fe
commit 0449f63f53
16 changed files with 299 additions and 103 deletions
Download patch file Download diff file Expand all files Collapse all files

32
Doc/howto/functional.rst
View file

@ -3,12 +3,10 @@
********************************
:Author: \A. M. Kuchling
:Release: 0.30
:Release: 0.31
(This is a first draft. Please send comments/error reports/suggestions to
amk@amk.ca. This URL is probably not going to be the final location of the
document, so be careful about linking to it -- you may want to add a
disclaimer.)
amk@amk.ca.)
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
@ -49,17 +47,19 @@ Programming languages support decomposing problems in several different ways:
functional languages include the ML family (Standard ML, OCaml, and other
variants) and Haskell.
The designers of some computer languages have chosen one approach to programming
that's emphasized. 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.
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 frowns upon
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
@ -616,7 +616,7 @@ Built-in functions
Let's look in more detail at built-in functions often used with iterators.
Two Python's built-in functions, :func:`map` and :func:`filter`, are somewhat
Two of Python's built-in functions, :func:`map` and :func:`filter`, are somewhat
obsolete; they duplicate the features of list comprehensions but return actual
lists instead of iterators.
@ -842,8 +842,8 @@ Fredrik Lundh once suggested the following set of rules for refactoring uses of
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 that this lambda-free
style is better.
I really like these rules, but you're free to disagree
about whether this lambda-free style is better.
The itertools module