From 22246fdd9d660144de762ec348130671f1d02db2 Mon Sep 17 00:00:00 2001 From: Vinay Sajip Date: Wed, 20 Oct 2010 11:40:02 +0000 Subject: [PATCH] logging: clarified Filter documentation. --- Doc/library/logging.rst | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/Doc/library/logging.rst b/Doc/library/logging.rst index d42f7d73f7..0148ea9f5e 100644 --- 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 ^^^^^^^^^^^^^^^^^^^^^^ -- 2.49.0