[docs] [issue11997] One typo in Doc/c-api/init.rst

Steffen Daode Nurpmeso report at bugs.python.org
Wed May 4 11:59:44 CEST 2011


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

11997.1.diff only corrects the typo, 11997.2.diff does also
reformat.  (Note that all of init.rst is hard to read on a 80
column terminal.)

----------
keywords: +patch
Added file: http://bugs.python.org/file21880/11997.1.diff
Added file: http://bugs.python.org/file21881/11997.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11997>
_______________________________________
-------------- next part --------------
diff --git a/Doc/c-api/init.rst b/Doc/c-api/init.rst
--- a/Doc/c-api/init.rst
+++ b/Doc/c-api/init.rst
@@ -883,7 +883,7 @@
 modules.
 
 Also note that combining this functionality with :c:func:`PyGILState_\*` APIs
-is delicate, become these APIs assume a bijection between Python thread states
+is delicate, because these APIs assume a bijection between Python thread states
 and OS-level threads, an assumption broken by the presence of sub-interpreters.
 It is highly recommended that you don't switch sub-interpreters between a pair
 of matching :c:func:`PyGILState_Ensure` and :c:func:`PyGILState_Release` calls.
-------------- next part --------------
diff --git a/Doc/c-api/init.rst b/Doc/c-api/init.rst
--- a/Doc/c-api/init.rst
+++ b/Doc/c-api/init.rst
@@ -882,14 +882,14 @@
 by such objects may affect the wrong (sub-)interpreter's dictionary of loaded
 modules.
 
-Also note that combining this functionality with :c:func:`PyGILState_\*` APIs
-is delicate, become these APIs assume a bijection between Python thread states
-and OS-level threads, an assumption broken by the presence of sub-interpreters.
-It is highly recommended that you don't switch sub-interpreters between a pair
-of matching :c:func:`PyGILState_Ensure` and :c:func:`PyGILState_Release` calls.
-Furthermore, extensions (such as :mod:`ctypes`) using these APIs to allow calling
-of Python code from non-Python created threads will probably be broken when using
-sub-interpreters.
+Also note that combining this functionality with :c:func:`PyGILState_\*` APIs is
+delicate, because these APIs assume a bijection between Python thread states and
+OS-level threads, an assumption broken by the presence of sub-interpreters.  It
+is highly recommended that you don't switch sub-interpreters between a pair of
+matching :c:func:`PyGILState_Ensure` and :c:func:`PyGILState_Release` calls.
+Furthermore, extensions (such as :mod:`ctypes`) using these APIs to allow
+calling of Python code from non-Python created threads will probably be broken
+when using sub-interpreters.
 
 
 Asynchronous Notifications


More information about the docs mailing list