Merged revisions 60481,60485,60489-60492,60494-60496,60498-60499,60501-60503,60505-60506,60508-60509,60523-60524,60532,60543,60545,60547-60548,60552,60554,60556-60559,60561-60562,60569,60571-60572,60574,60576-60583,60585-60586,60589,60591,60594-60595,60597-60598,60600-60601,60606-60612,60615,60617,60619-60621,60623-60625,60627-60629,60631,60633,60635,60647,60650,60652,60654,60656,60658-60659,60664-60666,60668-60670,60672,60676,60678,60680-60683,60685-60686,60688,60690,60692-60694,60697-60700,60705-60706,60708,60711,60714,60720,60724-60730,60732,60736,60742,60744,60746,60748,60750-60751,60753,60756-60757,60759-60761,60763-60764,60766,60769-60770,60774-60784,60787-60789,60793,60796,60799-60809,60812-60813,60815-60821,60823-60826,60828-60829,60831-60834,60836,60838-60839,60846-60873 via svnmerge from

svn+ssh://pythondev@svn.python.org/python/trunk

........
  r60850 | amaury.forgeotdarc | 2008-02-16 01:16:50 +0100 (Sat, 16 Feb 2008) | 3 lines

  mmap.PROT_READ does not exists on win32;
  Skip this test created by r60830.
........
  r60851 | raymond.hettinger | 2008-02-16 02:22:54 +0100 (Sat, 16 Feb 2008) | 1 line

  Add __all__ to logging module.
........
  r60855 | georg.brandl | 2008-02-16 10:37:32 +0100 (Sat, 16 Feb 2008) | 2 lines

  #2120: broken links in advocacy document.
........
  r60860 | amaury.forgeotdarc | 2008-02-16 15:34:57 +0100 (Sat, 16 Feb 2008) | 23 lines

  Crashers of the day: Py_CLEAR must be used when there is a chance that the
  function can be called recursively.
  This was discussed in issue1020188.

  In python codebase, all occurrences of Py_[X]DECREF(xxx->yyy) are suspect,
  except when they appear in tp_new or tp_dealloc functions, or when
  the member cannot be of a user-defined class.
  Note that tp_init is not safe.

  I do have a (crashing) example for every changed line.
  Is it worth adding them to the test suite?

  Example:

  class SpecialStr(str):
      def __del__(self):
          s.close()

  import cStringIO
  s = cStringIO.StringIO(SpecialStr("text"))
  s.close() # Segfault
........
  r60871 | amaury.forgeotdarc | 2008-02-16 21:55:24 +0100 (Sat, 16 Feb 2008) | 3 lines

  Prevent a crash with nested scopes, again caused by calling Py_DECREF when the pointer
  is still present in the containing structure.
........
  r60872 | brett.cannon | 2008-02-17 02:59:18 +0100 (Sun, 17 Feb 2008) | 4 lines

  Move test_logging over to doctest.

  Thanks to Christopher White from GHOP.
........
  r60873 | georg.brandl | 2008-02-17 12:33:38 +0100 (Sun, 17 Feb 2008) | 2 lines

  #2131: note that codecs.open() always opens files in binary mode.
........

2 files changed, 14 insertions, 6 deletions

diff --git a/Doc/howto/advocacy.rst b/Doc/howto/advocacy.rst
index 669ce72..407bf9f 100644
--- a/Doc/howto/advocacy.rst
+++ b/Doc/howto/advocacy.rst
@@ -160,7 +160,7 @@ for "compact":
    don't merge cleanly into the overall design scheme (thus, some fans of Classic C
    maintain that ANSI C is no longer compact).
 
-   (From http://www.catb.org/ esr/jargon/html/C/compact.html)
+   (From http://www.catb.org/~esr/jargon/html/C/compact.html)
 
 In this sense of the word, Python is quite compact, because the language has
 just a few ideas, which are used in lots of places.  Take namespaces, for
@@ -174,14 +174,14 @@ standard dictionary data type: .keys() returns all the keys, and so forth.
 This simplicity arises from Python's development history.  The language syntax
 derives from different sources; ABC, a relatively obscure teaching language, is
 one primary influence, and Modula-3 is another.  (For more information about ABC
-and Modula-3, consult their respective Web sites at http://www.cwi.nl/
-steven/abc/ and http://www.m3.org.)  Other features have come from C, Icon,
+and Modula-3, consult their respective Web sites at http://www.cwi.nl/~steven/abc/
+and http://www.m3.org.)  Other features have come from C, Icon,
 Algol-68, and even Perl.  Python hasn't really innovated very much, but instead
 has tried to keep the language small and easy to learn, building on ideas that
 have been tried in other languages and found useful.
 
 Simplicity is a virtue that should not be underestimated.  It lets you learn the
-language more quickly, and then rapidly write code, code that often works the
+language more quickly, and then rapidly write code -- code that often works the
 first time you run it.
 
 
@@ -266,7 +266,7 @@ the  organizations that use Python.
 
 They're practically nonexistent.  Consult the :file:`Misc/COPYRIGHT` file in the
 source distribution, or the section :ref:`history-and-license` for the full
-language, but it boils down to three conditions.
+language, but it boils down to three conditions:
 
 * You have to leave the copyright notice on the software; if you don't include
   the source code in a product, you have to put the copyright notice in the
diff --git a/Doc/library/codecs.rst b/Doc/library/codecs.rst
index ae79049..1491213 100644
--- a/Doc/library/codecs.rst
+++ b/Doc/library/codecs.rst
@@ -202,7 +202,8 @@ utility functions:
 .. function:: open(filename, mode[, encoding[, errors[, buffering]]])
 
    Open an encoded file using the given *mode* and return a wrapped version
-   providing transparent encoding/decoding.
+   providing transparent encoding/decoding.  The default file mode is ``'r'``
+   meaning to open the file in read mode.
 
    .. note::
 
@@ -210,6 +211,13 @@ utility functions:
       i.e. Unicode objects for most built-in codecs.  Output is also codec-dependent
       and will usually be Unicode as well.
 
+   .. note::
+
+      Files are always opened in binary mode, even if no binary mode was
+      specified.  This is done to avoid data loss due to encodings using 8-bit
+      values.  This means that no automatic conversion of ``'\n'`` is done
+      on reading and writing.
+
    *encoding* specifies the encoding which is to be used for the file.
 
    *errors* may be given to define the error handling. It defaults to ``'strict'``