summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRaymond Hettinger <python@rcn.com>2014-12-11 23:56:32 -0800
committerRaymond Hettinger <python@rcn.com>2014-12-11 23:56:32 -0800
commit339e25e995702f6538d3edf9f7d4152514d128be (patch)
treee1d52cefc67e877fe6b60a8895f87cd3506529e5
parentde45172262270798ee79dba266dced2faf6f58ce (diff)
downloadcpython-339e25e995702f6538d3edf9f7d4152514d128be.tar.gz
Issue 23005: Fix typos
-rw-r--r--Doc/library/heapq.rst4
1 files changed, 2 insertions, 2 deletions
diff --git a/Doc/library/heapq.rst b/Doc/library/heapq.rst
index 6a6148025b..43088ad9e3 100644
--- a/Doc/library/heapq.rst
+++ b/Doc/library/heapq.rst
@@ -260,11 +260,11 @@ However, there are other representations which are more efficient overall, yet
the worst cases might be terrible.
Heaps are also very useful in big disk sorts. You most probably all know that a
-big sort implies producing "runs" (which are pre-sorted sequences, which size is
+big sort implies producing "runs" (which are pre-sorted sequences, whose size is
usually related to the amount of CPU memory), followed by a merging passes for
these runs, which merging is often very cleverly organised [#]_. It is very
important that the initial sort produces the longest runs possible. Tournaments
-are a good way to that. If, using all the memory available to hold a
+are a good way to achieve that. If, using all the memory available to hold a
tournament, you replace and percolate items that happen to fit the current run,
you'll produce runs which are twice the size of the memory for random input, and
much better for input fuzzily ordered.