Merged revisions 85731,85735 via svnmerge from

svn+ssh://pythondev@svn.python.org/python/branches/py3k

........
  r85731 | georg.brandl | 2010-10-19 23:07:16 +0200 (Di, 19 Okt 2010) | 1 line

  Be consistent in the spelling of thread-safe(ty).
........
  r85735 | georg.brandl | 2010-10-20 08:50:19 +0200 (Mi, 20 Okt 2010) | 1 line

  Fix r85728: use "" to mean the system default locale, which should work on more systems.
........

6 files changed, 11 insertions, 14 deletions

diff --git a/Doc/c-api/init.rst b/Doc/c-api/init.rst
index d13009f..392a7a9 100644
--- a/Doc/c-api/init.rst
+++ b/Doc/c-api/init.rst
@@ -418,7 +418,7 @@ Thread State and the Global Interpreter Lock
    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
diff --git a/Doc/library/locale.rst b/Doc/library/locale.rst
index 7b4a05f..a668b2d 100644
--- a/Doc/library/locale.rst
+++ b/Doc/library/locale.rst
@@ -40,7 +40,7 @@ The :mod:`locale` module defines the following exception and functions:
    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
diff --git a/Doc/library/multiprocessing.rst b/Doc/library/multiprocessing.rst
index b49e439..f4e4a8e 100644
--- a/Doc/library/multiprocessing.rst
+++ b/Doc/library/multiprocessing.rst
@@ -216,7 +216,7 @@ However, if you really do need to use some shared data then
    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
diff --git a/Doc/library/runpy.rst b/Doc/library/runpy.rst
index 23d0730..905c64b 100644
--- a/Doc/library/runpy.rst
+++ b/Doc/library/runpy.rst
@@ -120,7 +120,7 @@ The :mod:`runpy` module provides two functions:
 
    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.
 
diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst
index b22d3d1..cd3f963 100644
--- a/Doc/library/threading.rst
+++ b/Doc/library/threading.rst
@@ -781,9 +781,9 @@ Currently, :class:`Lock`, :class:`RLock`, :class:`Condition`,
 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
diff --git a/Lib/test/test_calendar.py b/Lib/test/test_calendar.py
index 8396bdf..f20cc03 100644
--- a/Lib/test/test_calendar.py
+++ b/Lib/test/test_calendar.py
@@ -252,16 +252,13 @@ class CalendarTestCase(unittest.TestCase):
     def test_localecalendars(self):
         # ensure that Locale{Text,HTML}Calendar resets the locale properly
         # (it is still not thread-safe though)
+        old_october = calendar.TextCalendar().formatmonthname(2010, 10, 10)
         try:
-            def_locale = locale.getdefaultlocale()
+            calendar.LocaleTextCalendar(locale='').formatmonthname(2010, 10, 10)
         except locale.Error:
-            # cannot determine a default locale -- skip test
+            # cannot set the system default locale -- skip rest of test
             return
-        old_october = calendar.TextCalendar().formatmonthname(2010, 10, 10)
-        calendar.LocaleTextCalendar(
-            locale=def_locale).formatmonthname(2010, 10, 10)
-        calendar.LocaleHTMLCalendar(
-            locale=def_locale).formatmonthname(2010, 10)
+        calendar.LocaleHTMLCalendar(locale='').formatmonthname(2010, 10)
         new_october = calendar.TextCalendar().formatmonthname(2010, 10, 10)
         self.assertEquals(old_october, new_october)