diff options
Diffstat (limited to 'Doc')
| -rw-r--r-- | Doc/conf.py | 2 | ||||
| -rw-r--r-- | Doc/library/itertools.rst | 46 | ||||
| -rw-r--r-- | Doc/library/thread.rst | 6 | ||||
| -rw-r--r-- | Doc/library/threading.rst | 7 |
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 |