traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

logging: clarified Filter documentation.

This commit is contained in:
Vinay Sajip 2010-10-20 11:40:02 +00:00
parent 9450cc056a
commit 22246fdd9d
1 changed files with 10 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Doc/library/logging.rst
View File

@ -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
^^^^^^^^^^^^^^^^^^^^^^