The format method of logging.Formatter is buggy in that
it doesn't call the method formatException if the cache
record.exc_text is set. If you have two Formatters that
should format the same log record differently (i.e. each
has its own overriding formatException method), the
formatException method of the second formatter will
never be called because the cache has been set by the
first formatter. The proper way of using the cache is
IMHO to check the cache only in the method
formatException of logging.Formatter.

Logged In: YES 
user_id=308438

It's not a bug, it's by design. The formatException method
only takes the exception info as a parameter, and to change
the  method signature now could break some people's code, right?

A solution would be for you to also override the format
method in your custom formatter classes and set
record.exc_text to None if you want to invalidate the cache
before calling the base class implementation.

Logged In: YES 
user_id=1535177

Hi vsajip,
yes, it is by design, but I don't know whether the design is
ideal. But if this behaviour is really intended, it should
be documented clearly, such as:
formatException(exc_info): If you override this method, an
exception in the log record will be formatted by using this
method, but only if this log record wasn't given by the
framework to another formatter (that uses the default format
function) before your formatter got its turn (something you
cannot ensure)...

Now to the question of how to fix the design (provided one
wants to): clearly one cannot change the signature of
formatException without breaking existing code. But one
could change formatter to have an additional field
'labeledCache': a pair of an exc_info tuple and a string
(the cache). The formatException method would then use this
cache only if id() of its argument is the id() of the first
element in the pair, otherwise it would exchange
'labeledCache' by a new pair belonging to the current
exc_info tuple. That's only one posibility to fix this problem.

Logged In: YES 
user_id=308438

Hi Boris,

You didn't say in your comment what was wrong with my 
suggestion (setting record.exc_text to None in your 
formatter subclass).

I take your point, and understand your labeledCache 
suggestion, and will look at implementing something 
equivalent when time permits. However, other scenarios need 
to be considered, such as sending LogRecords over the wire. 
In this scenario (not uncommon in multi-process 
environments), the present implementation could send the 
formatted stack trace, as it is pickled in the LogRecord; 
implementing a cache in the Formatter will not allow the 
stack trace to be sent to be logged elsewhwere.

Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).