[Python-checkins] r85731 - in python/branches/py3k/Doc: c-api/init.rst library/locale.rst library/multiprocessing.rst library/runpy.rst library/threading.rst

[georg.brandl]

Author: georg.brandl
Date: Tue Oct 19 23:07:16 2010
New Revision: 85731

Log:
Be consistent in the spelling of thread-safe(ty).

Modified:
   python/branches/py3k/Doc/c-api/init.rst
   python/branches/py3k/Doc/library/locale.rst
   python/branches/py3k/Doc/library/multiprocessing.rst
   python/branches/py3k/Doc/library/runpy.rst
   python/branches/py3k/Doc/library/threading.rst

Modified: python/branches/py3k/Doc/c-api/init.rst
==============================================================================
--- python/branches/py3k/Doc/c-api/init.rst	(original)
+++ python/branches/py3k/Doc/c-api/init.rst	Tue Oct 19 23:07:16 2010
@@ -437,7 +437,7 @@
    single: interpreter lock
    single: lock, interpreter
 
-The Python interpreter is not fully thread safe.  In order to support
+The Python interpreter is not fully thread-safe.  In order to support
 multi-threaded Python programs, there's a global lock, called the :dfn:`global
 interpreter lock` or :dfn:`GIL`, that must be held by the current thread before
 it can safely access Python objects. Without the lock, even the simplest

Modified: python/branches/py3k/Doc/library/locale.rst
==============================================================================
--- python/branches/py3k/Doc/library/locale.rst	(original)
+++ python/branches/py3k/Doc/library/locale.rst	Tue Oct 19 23:07:16 2010
@@ -39,7 +39,7 @@
    If *locale* is omitted or ``None``, the current setting for *category* is
    returned.
 
-   :func:`setlocale` is not thread safe on most systems. Applications typically
+   :func:`setlocale` is not thread-safe on most systems. Applications typically
    start with a call of ::
 
       import locale

Modified: python/branches/py3k/Doc/library/multiprocessing.rst
==============================================================================
--- python/branches/py3k/Doc/library/multiprocessing.rst	(original)
+++ python/branches/py3k/Doc/library/multiprocessing.rst	Tue Oct 19 23:07:16 2010
@@ -214,7 +214,7 @@
    The ``'d'`` and ``'i'`` arguments used when creating ``num`` and ``arr`` are
    typecodes of the kind used by the :mod:`array` module: ``'d'`` indicates a
    double precision float and ``'i'`` indicates a signed integer.  These shared
-   objects will be process and thread safe.
+   objects will be process and thread-safe.
 
    For more flexibility in using shared memory one can use the
    :mod:`multiprocessing.sharedctypes` module which supports the creation of

Modified: python/branches/py3k/Doc/library/runpy.rst
==============================================================================
--- python/branches/py3k/Doc/library/runpy.rst	(original)
+++ python/branches/py3k/Doc/library/runpy.rst	Tue Oct 19 23:07:16 2010
@@ -120,7 +120,7 @@
 
    Note that, unlike :func:`run_module`, the alterations made to :mod:`sys`
    are not optional in this function as these adjustments are essential to
-   allowing the execution of sys.path entries. As the thread safety
+   allowing the execution of sys.path entries. As the thread-safety
    limitations still apply, use of this function in threaded code should be
    either serialised with the import lock or delegated to a separate process.
 

Modified: python/branches/py3k/Doc/library/threading.rst
==============================================================================
--- python/branches/py3k/Doc/library/threading.rst	(original)
+++ python/branches/py3k/Doc/library/threading.rst	Tue Oct 19 23:07:16 2010
@@ -789,9 +789,9 @@
 Importing in threaded code
 --------------------------
 
-While the import machinery is thread safe, there are two key
-restrictions on threaded imports due to inherent limitations in the way
-that thread safety is provided:
+While the import machinery is thread-safe, there are two key restrictions on
+threaded imports due to inherent limitations in the way that thread-safety is
+provided:
 
 * Firstly, other than in the main module, an import should not have the
   side effect of spawning a new thread and then waiting for that thread in