[Python-checkins] cpython (2.7): Some formatting & grammar fixes for the multiprocessing doc

Sat Dec 31 06:05:20 CET 2011

http://hg.python.org/cpython/rev/fb5ad61a2b35
changeset: 74203:fb5ad61a2b35
branch: 2.7
parent: 74200:5adbc87f1028
user: Eli Bendersky <eliben at gmail.com>
date: Sat Dec 31 07:05:12 2011 +0200
summary:
 Some formatting & grammar fixes for the multiprocessing doc
files:
 Doc/library/multiprocessing.rst | 34 ++++++++++----------
 1 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/Doc/library/multiprocessing.rst b/Doc/library/multiprocessing.rst
--- a/Doc/library/multiprocessing.rst
+++ b/Doc/library/multiprocessing.rst
@@ -282,7 +282,7 @@
 
 if __name__ == '__main__':
 pool = Pool(processes=4) # start 4 worker processes
- result = pool.apply_async(f, [10]) # evaluate "f(10)" asynchronously
+ result = pool.apply_async(f, [10]) # evaluate "f(10)" asynchronously
 print result.get(timeout=1) # prints "100" unless your computer is *very* slow
 print pool.map(f, range(10)) # prints "[0, 1, 4,..., 81]"
 
@@ -472,7 +472,7 @@
 
 If you use :class:`JoinableQueue` then you **must** call
 :meth:`JoinableQueue.task_done` for each task removed from the queue or else the
-semaphore used to count the number of unfinished tasks may eventually overflow
+semaphore used to count the number of unfinished tasks may eventually overflow,
 raising an exception.
 
 Note that one can also create a shared queue by using a manager object -- see
@@ -490,7 +490,7 @@
 
 If a process is killed using :meth:`Process.terminate` or :func:`os.kill`
 while it is trying to use a :class:`Queue`, then the data in the queue is
- likely to become corrupted. This may cause any other processes to get an
+ likely to become corrupted. This may cause any other process to get an
 exception when it tries to use the queue later on.
 
 .. warning::
@@ -692,7 +692,7 @@
 (By default :data:`sys.executable` is used). Embedders will probably need to
 do some thing like ::
 
- setExecutable(os.path.join(sys.exec_prefix, 'pythonw.exe'))
+ set_executable(os.path.join(sys.exec_prefix, 'pythonw.exe'))
 
 before they can create child processes. (Windows only)
 
@@ -711,7 +711,7 @@
 Connection objects allow the sending and receiving of picklable objects or
 strings. They can be thought of as message oriented connected sockets.
 
-Connection objects usually created using :func:`Pipe` -- see also
+Connection objects are usually created using :func:`Pipe` -- see also
 :ref:`multiprocessing-listeners-clients`.
 
 .. class:: Connection
@@ -722,7 +722,7 @@
 using :meth:`recv`.
 
 The object must be picklable. Very large pickles (approximately 32 MB+,
- though it depends on the OS) may raise a ValueError exception.
+ though it depends on the OS) may raise a :exc:`ValueError` exception.
 
 .. method:: recv()
 
@@ -732,7 +732,7 @@
 
 .. method:: fileno()
 
- Returns the file descriptor or handle used by the connection.
+ Return the file descriptor or handle used by the connection.
 
 .. method:: close()
 
@@ -756,7 +756,7 @@
 If *offset* is given then data is read from that position in *buffer*. If
 *size* is given then that many bytes will be read from buffer. Very large
 buffers (approximately 32 MB+, though it depends on the OS) may raise a
- ValueError exception
+ :exc:`ValueError` exception
 
 .. method:: recv_bytes([maxlength])
 
@@ -1329,7 +1329,7 @@
 >>>>>>>>>>>>>>>>>>>
 
 To create one's own manager, one creates a subclass of :class:`BaseManager` and
-use the :meth:`~BaseManager.register` classmethod to register new types or
+uses the :meth:`~BaseManager.register` classmethod to register new types or
 callables with the manager class. For example::
 
 from multiprocessing.managers import BaseManager
@@ -1579,10 +1579,10 @@
 
 .. method:: apply(func[, args[, kwds]])
 
- Equivalent of the :func:`apply` built-in function. It blocks till the
- result is ready. Given this blocks, :meth:`apply_async` is better suited
- for performing work in parallel. Additionally, the passed
- in function is only executed in one of the workers of the pool.
+ Equivalent of the :func:`apply` built-in function. It blocks until the
+ result is ready, so :meth:`apply_async` is better suited for performing
+ work in parallel. Additionally, *func* is only executed in one of the
+ workers of the pool.
 
 .. method:: apply_async(func[, args[, kwds[, callback]]])
 
@@ -1596,7 +1596,7 @@
 .. method:: map(func, iterable[, chunksize])
 
 A parallel equivalent of the :func:`map` built-in function (it supports only
- one *iterable* argument though). It blocks till the result is ready.
+ one *iterable* argument though). It blocks until the result is ready.
 
 This method chops the iterable into a number of chunks which it submits to
 the process pool as separate tasks. The (approximate) size of these
@@ -2046,7 +2046,7 @@
 On Windows many types from :mod:`multiprocessing` need to be picklable so
 that child processes can use them. However, one should generally avoid
 sending shared objects to other processes using pipes or queues. Instead
- you should arrange the program so that a process which need access to a
+ you should arrange the program so that a process which needs access to a
 shared resource created elsewhere can inherit it from an ancestor process.
 
 Avoid terminating processes
@@ -2125,7 +2125,7 @@
 for i in range(10):
 Process(target=f, args=(lock,)).start()
 
-Beware replacing sys.stdin with a "file like object"
+Beware of replacing :data:`sys.stdin` with a "file like object"
 
 :mod:`multiprocessing` originally unconditionally called::
 
@@ -2243,7 +2243,7 @@
 
 
 An example showing how to use queues to feed tasks to a collection of worker
-process and collect the results:
+processes and collect the results:
 
 .. literalinclude:: ../includes/mp_workers.py
 
-- 
Repository URL: http://hg.python.org/cpython
