mirror of
https://github.com/python/cpython.git
synced 2024-11-25 02:44:06 +08:00
logging: clarified Filter documentation.
This commit is contained in:
parent
9450cc056a
commit
22246fdd9d
@ -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
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
Loading…
Reference in New Issue
Block a user