A filter added to, say, logging.getLogger('a').addFilter() never gets
the chance to filter messages logged into logging.getLogger('a.b').

On logging.Logger.handle() the current logger filters are called to
check if the message should be processed or not, but the logger parent
filters are not consulted (and this is ok, IMHO, more generic filters
shouldn't clobber messages of more specific loggers).

However, if none of the current filters block the message,
Logger.handle() then calls Logger.callHandlers(), which calls the
handlers of the current logger and of all the parent loggers as long as
each logger in the hierarchy allows the message to propagate. This is
done without consulting the parent loggers filters.

This means parent handlers get called to process log records even if the
parent logger filters would have otherwise blocked them.

Attached is a very crude patch that allows the parent loggers to filter
events before handling them. I'd prefer to simply call the "handle()" 
or "callHandler()" method of the parent loggers recursively, but
couldn't find a way to do this while still preserving the method
signatures AND properly reporting when no handler could be found.

My preference would be to have callHandlers() do the filtering AND
return a number of handlers invoked, including the parent handlers, so
that handle() could report if no handlers could be found.

This behaviour is by design. Messages logged to logger 'a.b' are not
passed to logger 'a' - they are passed to *the handlers* of logger 'a'
(and so on up until a false value is seen for the logger's 'propagate'
attribute). In this respect, filtering works in the same way as levels
do - for example if logger 'a' has a level of WARNING and logger 'a.b'
has a level of DEBUG, then DEBUG events logged to 'a.b' will still show
up in the logs.

Closing, as it's not a bug, and implementing the alternative would not
be backwards compatible.

At the very least this is a documentation bug. By reading the std docs
on the logging module [1] one gets the impression that if a log record
gets to a certain logger, even if percolated from more specific loggers,
then the filters to that logger should be involved and even get the
chance to change the log record.

[1] http://docs.python.org/library/logging.html

This is reinforced by the documentation and the implementation of the
logging.Filter class, which is supposed to filter-out messages of more
specific loggers, but which would never actually filter out anything if
applied to a Logger of the same "name" (as opposed to a Handler, since
filter handlers do get called for log records of more specific loggers).

> Leonardo Rochael Almeida  added the comment:

> 
> At the very least this is a documentation bug. By reading the std docs
> on the logging module [1] one gets the impression that if a log record
> gets to a certain logger, even if percolated from more specific loggers,
> then the filters to that logger should be involved and even get the
> chance to change the log record.
> 
> [1] http://docs.python.org/library/logging.html
> 
> This is reinforced by the documentation and the implementation of the
> logging.Filter class, which is supposed to filter-out messages of more
> specific loggers, but which would never actually filter out anything if
> applied to a Logger of the same "name" (as opposed to a Handler, since
> filter handlers do get called for log records of more specific loggers).
> 

Can you say more specifically which part of this document you think is misleading? For example, the Filter documentation says "Filters can be used by Handlers and Loggers for
more sophisticated filtering than is provided by levels." Now this documentation does also mention how the default Filter implementation works, which does refer to loggers and their children - but that's just a specific implementation of a Filter which allows through some part of the logger namespace hierarchy. (It just looks at the logger name to decide whether to let an event through or not.) It's not a statement about how Filters work in general.

If you can confirm which parts of the logging documentation you think need to be changed (feel free to suggest alternative wording or additional wording) I'll certainly try to make those parts clearer.