Issue 1501699: method format of logging.Formatter caches incorrectly (original) (raw)

Created on 2006-06-06 15:14 by blorbeer, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg28724 - (view)	Author: Boris Lorbeer (blorbeer)	Date: 2006-06-06 15:14
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.
msg28725 - (view)	Author: Vinay Sajip (vinay.sajip) *	Date: 2006-06-22 16:46
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.
msg28726 - (view)	Author: Boris Lorbeer (blorbeer)	Date: 2006-06-23 14:01
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.
msg28727 - (view)	Author: Vinay Sajip (vinay.sajip) *	Date: 2006-06-23 14:56
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.
msg28728 - (view)	Author: SourceForge Robot (sf-robot)	Date: 2006-07-08 02:20
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).