Merged revisions 61038,61042-61045,61047,61050,61053,61055-61056,61061-61064,61066-61080 via svnmerge from

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

........
  r61063 | andrew.kuchling | 2008-02-25 17:29:19 +0100 (Mon, 25 Feb 2008) | 1 line

  Move .setupterm() output so that we don't try to call endwin() if it fails
........
  r61064 | andrew.kuchling | 2008-02-25 17:29:58 +0100 (Mon, 25 Feb 2008) | 1 line

  Use file descriptor for real stdout
........
  r61067 | facundo.batista | 2008-02-25 19:06:00 +0100 (Mon, 25 Feb 2008) | 4 lines


  Issue 2117.  Update compiler module to handle class decorators.
  Thanks Thomas Herve
........
  r61069 | georg.brandl | 2008-02-25 21:17:56 +0100 (Mon, 25 Feb 2008) | 2 lines

  Rename sphinx.addons to sphinx.ext.
........
  r61071 | georg.brandl | 2008-02-25 21:20:45 +0100 (Mon, 25 Feb 2008) | 2 lines

  Revert r61029.
........
  r61072 | facundo.batista | 2008-02-25 23:33:55 +0100 (Mon, 25 Feb 2008) | 4 lines


  Issue 2168. gdbm and dbm needs to be iterable; this fixes a
  failure in the shelve module.  Thanks Thomas Herve.
........
  r61073 | raymond.hettinger | 2008-02-25 23:42:32 +0100 (Mon, 25 Feb 2008) | 1 line

  Make sure the itertools filter functions give the same performance for func=bool as func=None.
........
  r61074 | raymond.hettinger | 2008-02-26 00:17:41 +0100 (Tue, 26 Feb 2008) | 1 line

  Revert part of r60927 which made invalid assumptions about the API offered by db modules.
........
  r61075 | facundo.batista | 2008-02-26 00:46:02 +0100 (Tue, 26 Feb 2008) | 3 lines


  Coerced PyBool_Type to be able to compare it.
........
  r61076 | raymond.hettinger | 2008-02-26 03:46:54 +0100 (Tue, 26 Feb 2008) | 1 line

  Docs for itertools.combinations().  Implementation in forthcoming checkin.
........
  r61077 | neal.norwitz | 2008-02-26 05:50:37 +0100 (Tue, 26 Feb 2008) | 3 lines

  Don't use a hard coded port.  This test could hang/fail if the port is in use.
  Speed this test up by avoiding a sleep and using the event.
........
  r61078 | neal.norwitz | 2008-02-26 06:12:50 +0100 (Tue, 26 Feb 2008) | 1 line

  Whitespace normalization
........
  r61079 | neal.norwitz | 2008-02-26 06:23:51 +0100 (Tue, 26 Feb 2008) | 1 line

  Whitespace normalization
........
  r61080 | georg.brandl | 2008-02-26 07:40:10 +0100 (Tue, 26 Feb 2008) | 2 lines

  Banish tab.
........

4 files changed, 46 insertions, 15 deletions

diff --git a/Doc/conf.py b/Doc/conf.py
index 5b3b42e..b7903be 100644
--- a/Doc/conf.py
+++ b/Doc/conf.py
@@ -13,7 +13,7 @@ sys.path.append('tools/sphinxext')
 # General configuration
 # ---------------------
 
-extensions = ['sphinx.addons.refcounting', 'sphinx.addons.coverage']
+extensions = ['sphinx.ext.refcounting', 'sphinx.ext.coverage']
 
 # General substitutions.
 project = 'Python'
diff --git a/Doc/library/itertools.rst b/Doc/library/itertools.rst
index af73b57..d04f33b 100644
--- a/Doc/library/itertools.rst
+++ b/Doc/library/itertools.rst
@@ -74,6 +74,45 @@ loops that truncate the stream.
                   yield element
 
 
+.. function:: combinations(iterable, r)
+
+   Return successive *r* length combinations of elements in the *iterable*.
+
+   Combinations are emitted in a lexicographic sort order.  So, if the 
+   input *iterable* is sorted, the combination tuples will be produced
+   in sorted order.  
+
+   Elements are treated as unique based on their position, not on their
+   value.  So if the input elements are unique, there will be no repeat
+   values within a single combination.
+
+   Each result tuple is ordered to match the input order.  So, every
+   combination is a subsequence of the input *iterable*.
+
+   Example:  ``combinations(range(4), 3) --> (0,1,2), (0,1,3), (0,2,3), (1,2,3)``
+
+   Equivalent to::
+
+        def combinations(iterable, r):
+            pool = tuple(iterable)
+            if pool:
+                n = len(pool)
+                vec = range(r)
+                yield tuple(pool[i] for i in vec)
+                while 1:
+                    for i in reversed(range(r)):
+                        if vec[i] == i + n-r:
+                            continue
+                        vec[i] += 1
+                        for j in range(i+1, r):
+                            vec[j] = vec[j-1] + 1
+                        yield tuple(pool[i] for i in vec)
+                        break
+                    else:
+                        return
+
+   .. versionadded:: 2.6
+
 .. function:: count([n])
 
    Make an iterator that returns consecutive integers starting with *n*. If not
@@ -298,9 +337,12 @@ loops that truncate the stream.
 
    The leftmost iterators are in the outermost for-loop, so the output tuples
    cycle in a manner similar to an odometer (with the rightmost element
-   changing on every iteration).
+   changing on every iteration).  This results in a lexicographic ordering
+   so that if the inputs iterables are sorted, the product tuples are emitted
+   in sorted order.
 
-   Equivalent to (but without building the entire result in memory)::
+   Equivalent to the following except that the actual implementation does not
+   build-up intermediate results in memory::
 
        def product(*args):
            pools = map(tuple, args)
diff --git a/Doc/library/thread.rst b/Doc/library/thread.rst
index d7d140e..31d58e7 100644
--- a/Doc/library/thread.rst
+++ b/Doc/library/thread.rst
@@ -147,11 +147,6 @@ In addition to these methods, lock objects can also be used via the
   exception will be received by an arbitrary thread.  (When the :mod:`signal`
   module is available, interrupts always go to the main thread.)
 
-* The import machinery is not thread safe.  In general, an import may not
-  have the side effect of importing a module, and only the main thread
-  should import modules.  Imports within or caused by a thread other than
-  the main thread isn't safe.
-
 * Calling :func:`sys.exit` or raising the :exc:`SystemExit` exception is
   equivalent to calling :func:`exit`.
 
@@ -172,3 +167,4 @@ In addition to these methods, lock objects can also be used via the
 * When the main thread exits, it does not do any of its usual cleanup (except
   that :keyword:`try` ... :keyword:`finally` clauses are honored), and the
   standard I/O files are not flushed.
+
diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst
index 56b2b99..6f3e95b 100644
--- a/Doc/library/threading.rst
+++ b/Doc/library/threading.rst
@@ -555,13 +555,6 @@ the :meth:`setDaemon` method and retrieved with the :meth:`isDaemon` method.
 There is a "main thread" object; this corresponds to the initial thread of
 control in the Python program.  It is not a daemon thread.
 
-.. warning::
-   
-   The import machinery is not thread safe.  In general, an import may not
-   have the side effect of importing a module, and only the main thread
-   should import modules.  Imports within or caused by a thread other than
-   the main thread isn't safe.
-
 There is the possibility that "dummy thread objects" are created. These are
 thread objects corresponding to "alien threads", which are threads of control
 started outside the threading module, such as directly from C code.  Dummy