6 files changed, 35 insertions, 19 deletions

diff --git a/Doc/howto/clinic.rst b/Doc/howto/clinic.rst
index 750ddbe074..ca8e1cb87b 100644
--- a/Doc/howto/clinic.rst
+++ b/Doc/howto/clinic.rst
@@ -886,7 +886,7 @@ Argument Clinic generates code that does it for you (in the parsing function).
 Advanced converters
 -------------------
 
-Remeber those format units you skipped for your first
+Remember those format units you skipped for your first
 time because they were advanced?  Here's how to handle those too.
 
 The trick is, all those format units take arguments--either
@@ -1020,12 +1020,12 @@ any of the default arguments you can omit the parentheses.
 the ``"as"`` should come before the return converter.)
 
 There's one additional complication when using return converters: how do you
-indicate an error has occured?  Normally, a function returns a valid (non-``NULL``)
+indicate an error has occurred?  Normally, a function returns a valid (non-``NULL``)
 pointer for success, and ``NULL`` for failure.  But if you use an integer return converter,
 all integers are valid.  How can Argument Clinic detect an error?  Its solution: each return
 converter implicitly looks for a special value that indicates an error.  If you return
 that value, and an error has been set (``PyErr_Occurred()`` returns a true
-value), then the generated code will propogate the error.  Otherwise it will
+value), then the generated code will propagate the error.  Otherwise it will
 encode the value you return like normal.
 
 Currently Argument Clinic supports only a few return converters::
@@ -1573,7 +1573,7 @@ The fourth new directive is ``set``::
 ``line_prefix`` is a string that will be prepended to every line of Clinic's output;
 ``line_suffix`` is a string that will be appended to every line of Clinic's output.
 
-Both of these suport two format strings:
+Both of these support two format strings:
 
   ``{block comment start}``
     Turns into the string ``/*``, the start-comment text sequence for C files.
diff --git a/Doc/howto/logging-cookbook.rst b/Doc/howto/logging-cookbook.rst
index 114ec09b74..e31b6c2bf4 100644
--- a/Doc/howto/logging-cookbook.rst
+++ b/Doc/howto/logging-cookbook.rst
@@ -325,6 +325,15 @@ which, when run, will produce::
 
     MainThread: Look out!
 
+.. versionchanged:: 3.5
+   Prior to Python 3.5, the :class:`QueueListener` always passed every message
+   received from the queue to every handler it was initialized with. (This was
+   because it was assumed that level filtering was all done on the other side,
+   where the queue is filled.) From 3.5 onwards, this behaviour can be changed
+   by passing a keyword argument ``respect_handler_level=True`` to the
+   listener's constructor. When this is done, the listener compares the level
+   of each message with the handler's level, and only passes a message to a
+   handler if it's appropriate to do so.
 
 .. _network-logging:
 
@@ -1680,7 +1689,7 @@ as in the following complete example::
 
     def main():
         logging.basicConfig(level=logging.INFO, format='%(message)s')
-        logging.info(_('message 1', set_value=set([1, 2, 3]), snowman='\u2603'))
+        logging.info(_('message 1', set_value={1, 2, 3}, snowman='\u2603'))
 
     if __name__ == '__main__':
         main()
diff --git a/Doc/howto/pyporting.rst b/Doc/howto/pyporting.rst
index 5e875cdee2..a2aaf367c7 100644
--- a/Doc/howto/pyporting.rst
+++ b/Doc/howto/pyporting.rst
@@ -207,13 +207,12 @@ that's ``str``/``bytes`` in Python 2 and ``bytes`` in Python 3). The following
 table lists the **unique** methods of each data type across Python 2 & 3
 (e.g., the ``decode()`` method is usable on the equivalent binary data type in
 either Python 2 or 3, but it can't be used by the text data type consistently
-between Python 2 and 3 because ``str`` in Python 3 doesn't have the method).
+between Python 2 and 3 because ``str`` in Python 3 doesn't have the method). Do
+note that as of Python 3.5 the ``__mod__`` method was added to the bytes type.
 
 ======================== =====================
 **Text data**            **Binary data**
 ------------------------ ---------------------
-__mod__ (``%`` operator)
------------------------- ---------------------
 \                        decode
 ------------------------ ---------------------
 encode
@@ -348,10 +347,12 @@ tox with your continuous integration system so that you never accidentally break
 Python 2 or 3 support.
 
 You may also want to use use the ``-bb`` flag with the Python 3 interpreter to
-trigger an exception when you are comparing bytes to strings. Usually it's
-simply ``False``, but if you made a mistake in your separation of text/binary
-data handling you may be accidentally comparing text and binary data. This flag
-will raise an exception when that occurs to help track down such cases.
+trigger an exception when you are comparing bytes to strings or bytes to an int
+(the latter is available starting in Python 3.5). By default type-differing
+comparisons simply return ``False``, but if you made a mistake in your
+separation of text/binary data handling or indexing on bytes you wouldn't easily
+find the mistake. This flag will raise an exception when these kinds of
+comparisons occur, making the mistake much easier to track down.
 
 And that's mostly it! At this point your code base is compatible with both
 Python 2 and 3 simultaneously. Your testing will also be set up so that you
diff --git a/Doc/howto/regex.rst b/Doc/howto/regex.rst
index fbe763b3f2..ad2c6ab7d5 100644
--- a/Doc/howto/regex.rst
+++ b/Doc/howto/regex.rst
@@ -852,7 +852,7 @@ keep track of the group numbers.  There are two features which help with this
 problem.  Both of them use a common syntax for regular expression extensions, so
 we'll look at that first.
 
-Perl 5 is well-known for its powerful additions to standard regular expressions.
+Perl 5 is well known for its powerful additions to standard regular expressions.
 For these new features the Perl developers couldn't choose new single-keystroke metacharacters
 or new special sequences beginning with ``\`` without making Perl's regular
 expressions confusingly different from standard REs.  If they chose ``&`` as a
@@ -1138,7 +1138,7 @@ Empty matches are replaced only when they're not adjacent to a previous match.
 
 If *replacement* is a string, any backslash escapes in it are processed.  That
 is, ``\n`` is converted to a single newline character, ``\r`` is converted to a
-carriage return, and so forth. Unknown escapes such as ``\j`` are left alone.
+carriage return, and so forth. Unknown escapes such as ``\&`` are left alone.
 Backreferences, such as ``\6``, are replaced with the substring matched by the
 corresponding group in the RE.  This lets you incorporate portions of the
 original text in the resulting replacement string.
diff --git a/Doc/howto/sockets.rst b/Doc/howto/sockets.rst
index d5aff9081d..04394d49f0 100644
--- a/Doc/howto/sockets.rst
+++ b/Doc/howto/sockets.rst
@@ -234,7 +234,7 @@ messages to be sent back to back (without some kind of reply), and you pass
 following message. You'll need to put that aside and hold onto it, until it's
 needed.
 
-Prefixing the message with it's length (say, as 5 numeric characters) gets more
+Prefixing the message with its length (say, as 5 numeric characters) gets more
 complex, because (believe it or not), you may not get all 5 characters in one
 ``recv``. In playing around, you'll get away with it; but in high network loads,
 your code will very quickly break unless you use two ``recv`` loops - the first
diff --git a/Doc/howto/unicode.rst b/Doc/howto/unicode.rst
index b49ac391ce..ee31a9c981 100644
--- a/Doc/howto/unicode.rst
+++ b/Doc/howto/unicode.rst
@@ -280,8 +280,9 @@ and optionally an *errors* argument.
 The *errors* argument specifies the response when the input string can't be
 converted according to the encoding's rules.  Legal values for this argument are
 ``'strict'`` (raise a :exc:`UnicodeDecodeError` exception), ``'replace'`` (use
-``U+FFFD``, ``REPLACEMENT CHARACTER``), or ``'ignore'`` (just leave the
-character out of the Unicode result).
+``U+FFFD``, ``REPLACEMENT CHARACTER``), ``'ignore'`` (just leave the
+character out of the Unicode result), or ``'backslashreplace'`` (inserts a
+``\xNN`` escape sequence).
 The following examples show the differences::
 
     >>> b'\x80abc'.decode("utf-8", "strict")  #doctest: +NORMALIZE_WHITESPACE
@@ -291,6 +292,8 @@ The following examples show the differences::
       invalid start byte
     >>> b'\x80abc'.decode("utf-8", "replace")
     '\ufffdabc'
+    >>> b'\x80abc'.decode("utf-8", "backslashreplace")
+    '\\x80abc'
     >>> b'\x80abc'.decode("utf-8", "ignore")
     'abc'
 
@@ -325,8 +328,9 @@ The *errors* parameter is the same as the parameter of the
 :meth:`~bytes.decode` method but supports a few more possible handlers. As well as
 ``'strict'``, ``'ignore'``, and ``'replace'`` (which in this case
 inserts a question mark instead of the unencodable character), there is
-also ``'xmlcharrefreplace'`` (inserts an XML character reference) and
-``backslashreplace`` (inserts a ``\uNNNN`` escape sequence).
+also ``'xmlcharrefreplace'`` (inserts an XML character reference),
+``backslashreplace`` (inserts a ``\uNNNN`` escape sequence) and
+``namereplace`` (inserts a ``\N{...}`` escape sequence).
 
 The following example shows the different results::
 
@@ -346,6 +350,8 @@ The following example shows the different results::
     b'ꀀabcd޴'
     >>> u.encode('ascii', 'backslashreplace')
     b'\\ua000abcd\\u07b4'
+    >>> u.encode('ascii', 'namereplace')
+    b'\\N{YI SYLLABLE IT}abcd\\u07b4'
 
 The low-level routines for registering and accessing the available
 encodings are found in the :mod:`codecs` module.  Implementing new