mirror of
https://github.com/python/cpython.git
synced 2025-08-03 08:34:29 +00:00
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. ........
This commit is contained in:
parent
34f8d3a4dd
commit
836baa53d8
13 changed files with 99 additions and 37 deletions
|
@ -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)
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue