python
diff --git a/‎Doc/extending/windows.rst‎
Lines changed: 8 additions & 4 deletions b/‎Doc/extending/windows.rst‎
Lines changed: 8 additions & 4 deletions
diff --git a/‎Doc/library/codecs.rst‎
Lines changed: 3 additions & 3 deletions b/‎Doc/library/codecs.rst‎
Lines changed: 3 additions & 3 deletions
diff --git a/‎Doc/library/ctypes.rst‎
Lines changed: 14 additions & 14 deletions b/‎Doc/library/ctypes.rst‎
Lines changed: 14 additions & 14 deletions
diff --git a/‎Doc/library/functions.rst‎
Lines changed: 12 additions & 12 deletions b/‎Doc/library/functions.rst‎
Lines changed: 12 additions & 12 deletions
diff --git a/‎Doc/library/http.server.rst‎
Lines changed: 5 additions & 0 deletions b/‎Doc/library/http.server.rst‎
Lines changed: 5 additions & 0 deletions
diff --git a/‎Doc/library/logging.rst‎
Lines changed: 45 additions & 4 deletions b/‎Doc/library/logging.rst‎
Lines changed: 45 additions & 4 deletions
diff --git a/‎Doc/library/math.rst‎
Lines changed: 1 addition & 1 deletion b/‎Doc/library/math.rst‎
Lines changed: 1 addition & 1 deletion
@@ -102,10 +102,14 @@ described here are distributed with the Python sources in the
    and it should call :cfunc:`Py_InitModule` with the string ``"spam"`` as its
    first argument (use the minimal :file:`example.c` in this directory as a guide).
    By convention, it lives in a file called :file:`spam.c` or :file:`spammodule.c`.
-   The output file should be called :file:`spam.dll` or :file:`spam.pyd` (the
-   latter is supported to avoid confusion with a system library :file:`spam.dll` to
-   which your module could be a Python interface) in Release mode, or
-   :file:`spam_d.dll` or :file:`spam_d.pyd` in Debug mode.
+   The output file should be called :file:`spam.pyd` (in Release mode) or  
+   :file:`spam_d.pyd` (in Debug mode). The extension :file:`.pyd` was chosen
+   to avoid confusion with a system library :file:`spam.dll` to which your module
+   could be a Python interface.
+
+   .. versionchanged:: 2.5
+      Previously, file names like :file:`spam.dll` (in release mode) or
+      :file:`spam_d.dll` (in debug mode) were also recognized.
 
    Now your options are:
 
 
@@ -51,13 +51,13 @@ It defines the following functions:
    Codec Interface). The functions/methods are expected to work in a stateless
    mode.
 
-   *incrementalencoder* and *incrementalencoder*: These have to be factory
+   *incrementalencoder* and *incrementaldecoder*: These have to be factory
    functions providing the following interface:
 
    ``factory(errors='strict')``
 
    The factory functions must return objects providing the interfaces defined by
-   the base classes :class:`IncrementalEncoder` and :class:`IncrementalEncoder`,
+   the base classes :class:`IncrementalEncoder` and :class:`IncrementalDecoder`,
    respectively. Incremental codecs can maintain state.
 
    *streamreader* and *streamwriter*: These have to be factory functions providing
@@ -478,7 +478,7 @@ define in order to be compatible with the Python codec registry.
 
    The *errors* argument will be assigned to an attribute of the same name.
    Assigning to this attribute makes it possible to switch between different error
-   handling strategies during the lifetime of the :class:`IncrementalEncoder`
+   handling strategies during the lifetime of the :class:`IncrementalDecoder`
    object.
 
    The set of allowed values for the *errors* argument can be extended with
 
@@ -8,7 +8,7 @@
 
 
 ``ctypes`` is a foreign function library for Python.  It provides C compatible
-data types, and allows calling functions in dlls/shared libraries.  It can be
+data types, and allows calling functions in DLLs or shared libraries.  It can be
 used to wrap these libraries in pure Python.
 
 
@@ -21,8 +21,8 @@ Note: The code samples in this tutorial use ``doctest`` to make sure that they
 actually work.  Since some code samples behave differently under Linux, Windows,
 or Mac OS X, they contain doctest directives in comments.
 
-Note: Some code sample references the ctypes :class:`c_int` type. This type is
-an alias to the :class:`c_long` type on 32-bit systems.  So, you should not be
+Note: Some code samples reference the ctypes :class:`c_int` type. This type is
+an alias for the :class:`c_long` type on 32-bit systems.  So, you should not be
 confused if :class:`c_long` is printed if you would expect :class:`c_int` ---
 they are actually the same type.
 
@@ -32,8 +32,8 @@ they are actually the same type.
 Loading dynamic link libraries
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-``ctypes`` exports the *cdll*, and on Windows also *windll* and *oledll* objects
-to load dynamic link libraries.
+``ctypes`` exports the *cdll*, and on Windows *windll* and *oledll*
+objects, for loading dynamic link libraries.
 
 You load libraries by accessing them as attributes of these objects. *cdll*
 loads libraries which export functions using the standard ``cdecl`` calling
@@ -315,7 +315,7 @@ property::
    >>> p = create_string_buffer("Hello", 10)  # create a 10 byte buffer
    >>> print(sizeof(p), repr(p.raw))
    10 'Hello\x00\x00\x00\x00\x00'
-   >>> p.value = "Hi"      
+   >>> p.value = "Hi"
    >>> print(sizeof(p), repr(p.raw))
    10 'Hi\x00lo\x00\x00\x00\x00\x00'
    >>>
@@ -906,7 +906,7 @@ other, and finally follow the pointer chain a few times::
    ...     p = p.next[0]
    ...
    foo bar foo bar foo bar foo bar
-   >>>    
+   >>>
 
 
 .. _ctypes-callback-functions:
@@ -2018,7 +2018,7 @@ Data types
 
    .. method:: _CData.from_buffer_copy(source[, offset])
 
-      This method creates a ctypes instance, the buffer is copied from
+      This method creates a ctypes instance, copying the buffer from
       the source object buffer which must be readable.  The optional
       ``offset`` parameter specifies an offset into the source buffer
       in bytes; the default is zero.  If the source buffer is not
@@ -2033,13 +2033,13 @@ Data types
 
    .. method:: from_param(obj)
 
-      This method adapts obj to a ctypes type.  It is called with the actual
-      object used in a foreign function call, when the type is present in the
-      foreign functions :attr:`argtypes` tuple; it must return an object that
-      can be used as function call parameter.
+      This method adapts *obj* to a ctypes type.  It is called with the actual
+      object used in a foreign function call when the type is present in the
+      foreign function's :attr:`argtypes` tuple; it must return an object that
+      can be used as a function call parameter.
 
-      All ctypes data types have a default implementation of this classmethod,
-      normally it returns ``obj`` if that is an instance of the type.  Some
+      All ctypes data types have a default implementation of this classmethod
+      that normally returns ``obj`` if that is an instance of the type.  Some
       types accept other objects as well.
 
 
 
@@ -372,10 +372,10 @@ are always available.  They are listed here in alphabetical order.
       >>> eval('x+1')
       2
 
-   This function can also be used to execute arbitrary code objects (such as those
-   created by :func:`compile`).  In this case pass a code object instead of a
-   string.  The code object must have been compiled passing ``'eval'`` as the
-   *kind* argument.
+   This function can also be used to execute arbitrary code objects (such as
+   those created by :func:`compile`).  In this case pass a code object instead
+   of a string.  If the code object has been compiled with ``'exec'`` as the
+   *kind* argument, :func:`eval`\'s return value will be ``None``.
 
    Hints: dynamic execution of statements is supported by the :func:`exec`
    function.  The :func:`globals` and :func:`locals` functions
@@ -1086,14 +1086,14 @@ are always available.  They are listed here in alphabetical order.
 
    .. XXX updated as per http://www.artima.com/weblogs/viewpost.jsp?thread=208549 but needs checking
 
-   Return the superclass of *type*.
-   
-   Calling :func:`super()` without arguments is equivalent to
-   ``super(this_class, first_arg)``. If called with one
-   argument the super object returned is unbound.  If called with two
-   arguments and the second argument is an object, ``isinstance(obj,
-   type)`` must be true.  If the second argument is a type,
-   ``issubclass(type2, type)`` must be true.
+
+   Return a "super" object that acts like the superclass of *type*.  If the
+   second argument is omitted the super object returned is unbound.  If the
+   second argument is an object, ``isinstance(obj, type)`` must be true.  If the
+   second argument is a type, ``issubclass(type2, type)`` must be
+   true. :func:`super` only works for :term:`new-style class`\es.  Calling
+   :func:`super()` without arguments is equivalent to ``super(this_class,
+   first_arg)``.
 
    A typical use for calling a cooperative superclass method is::
 
 
@@ -56,6 +56,11 @@ of which this module provides three different variants:
       Contains a tuple of the form ``(host, port)`` referring to the client's
       address.
 
+   .. attribute:: server
+
+      Contains the server instance.
+
+
    .. attribute:: command
 
       Contains the command (request type). For example, ``'GET'``.
 
@@ -420,6 +420,45 @@ You can see that the config file approach has a few advantages over the Python
 code approach, mainly separation of configuration and code and the ability of
 noncoders to easily modify the logging properties.
 
+Configuring Logging for a Library
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When developing a library which uses logging, some consideration needs to be
+given to its configuration. If the using application does not use logging, and
+library code makes logging calls, then a one-off message "No handlers could be
+found for logger X.Y.Z" is printed to the console. This message is intended
+to catch mistakes in logging configuration, but will confuse an application
+developer who is not aware of logging by the library.
+
+In addition to documenting how a library uses logging, a good way to configure
+library logging so that it does not cause a spurious message is to add a
+handler which does nothing. This avoids the message being printed, since a
+handler will be found: it just doesn't produce any output. If the library user
+configures logging for application use, presumably that configuration will add
+some handlers, and if levels are suitably configured then logging calls made
+in library code will send output to those handlers, as normal.
+
+A do-nothing handler can be simply defined as follows::
+
+    import logging
+
+    class NullHandler(logging.Handler):
+        def emit(self, record):
+            pass
+
+An instance of this handler should be added to the top-level logger of the
+logging namespace used by the library. If all logging by a library *foo* is
+done using loggers with names matching "foo.x.y", then the code::
+
+    import logging
+
+    h = NullHandler()
+    logging.getLogger("foo").addHandler(h)
+
+should have the desired effect. If an organisation produces a number of
+libraries, then the logger name specified can be "orgname.foo" rather than
+just "foo".
+
 
 Logging Levels
 --------------
@@ -1440,8 +1479,10 @@ subclasses. However, the :meth:`__init__` method in subclasses needs to call
 
 .. method:: Handler.close()
 
-   Tidy up any resources used by the handler. This version does nothing and is
-   intended to be implemented by subclasses.
+   Tidy up any resources used by the handler. This version does no output but
+   removes the handler from an internal list of handlers which is closed when
+   :func:`shutdown` is called. Subclasses should ensure that this gets called
+   from overridden :meth:`close` methods.
 
 
 .. method:: Handler.handle(record)
@@ -1503,7 +1544,7 @@ and :meth:`flush` methods).
 
       Flushes the stream by calling its :meth:`flush` method. Note that the
       :meth:`close` method is inherited from :class:`Handler` and so does
-      nothing, so an explicit :meth:`flush` call may be needed at times.
+      no output, so an explicit :meth:`flush` call may be needed at times.
 
 
 FileHandler
@@ -1821,7 +1862,7 @@ extensions for Python installed.
       source of event log entries. However, if you do this, you will not be able
       to see the events as you intended in the Event Log Viewer - it needs to be
       able to access the registry to get the .dll name. The current version does
-      not do this (in fact it doesn't do anything).
+      not do this.
 
 
    .. method:: emit(record)
 
@@ -290,7 +290,7 @@ The module also defines two mathematical constants:
    :exc:`OverflowError`, ``math.log(0L)`` may raise :exc:`ValueError` instead.
 
    All functions return a quiet *NaN* if at least one of the args is *NaN*.
-   Signaling *NaN*s raise an exception. The exception type still depends on the
+   Signaling *NaN*\s raise an exception. The exception type still depends on the
    platform and libm implementation. It's usually :exc:`ValueError` for *EDOM*
    and :exc:`OverflowError` for errno *ERANGE*.