5 files changed, 17 insertions, 11 deletions

diff --git a/Doc/howto/clinic.rst b/Doc/howto/clinic.rst
index 750ddbe..ca8e1cb 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 114ec09..57e23f9 100644
--- a/Doc/howto/logging-cookbook.rst
+++ b/Doc/howto/logging-cookbook.rst
@@ -1680,7 +1680,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/regex.rst b/Doc/howto/regex.rst
index fbe763b..9ae04d7 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
diff --git a/Doc/howto/sockets.rst b/Doc/howto/sockets.rst
index d5aff90..04394d4 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 b49ac39..ee31a9c 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