logging: clarified Filter documentation.

diff --git a/Doc/library/logging.rst b/Doc/library/logging.rst
index d42f7d73f7e20a5805cbdead32ea40510515aedc..0148ea9f5e6a199098f57cd455540587aeb5b64e 100644 (file)
--- a/Doc/library/logging.rst
+++ b/Doc/library/logging.rst
@@ -3068,14 +3068,18 @@ etc.) This means that events which have been generated by descendant loggers
 will not be filtered by a logger's filter setting, unless the filter has also
 been applied to those descendant loggers.
 
+You don't actually need to subclass ``Filter``: you can pass any instance
+which has a ``filter`` method with the same semantics.
+
 .. versionchanged:: 3.2
 
-You don't need to create specialized ``Filter`` classes: you can use a plain
-function (or other callable) as a filter. The filtering logic will check to
-see if the filter object has a ``filter`` attribute: if it does, it's assumed
-to be a ``Filter`` and its :meth:`~Filter.filter` method is called. Otherwise,
-it's assumed to be a callable and called with the record as the single
-parameter. The result should conform to that of :meth:`~Filter.filter`.
+You don't need to create specialized ``Filter`` classes, or use other classes
+with a ``filter`` method: you can use a function (or other callable) as a
+filter. The filtering logic will check to see if the filter object has a
+``filter`` attribute: if it does, it's assumed to be a ``Filter`` and its
+:meth:`~Filter.filter` method is called. Otherwise, it's assumed to be a
+callable and called with the record as the single parameter. The returned
+value should conform to that returned by :meth:`~Filter.filter`.
 
 Other uses for filters
 ^^^^^^^^^^^^^^^^^^^^^^