[Python-Dev] PEP282 and the warnings framework
Thu, 16 May 2002 02:54:08 +0200
Vinay Sajip wrote:
> So far, I am not sure what benefit switching from the status quo of
> integer-based levels to class-based levels will give. Certainly, the idea of
> relative levels of importance of events must be preserved, since
> severity-based filtering is a key function of logging.
first off, the DebugMessage/InfoMessage/... could
have a class-level severity property (integer) if one
really wants to have it for compatibility etc.
this leaves the question how a Message-instance/type is more
powerful than a tuple(string/integer).
Some thoughts regarding Message-instances/types:
- the convenient logging API and categorization features
need *not* be changed largely (but the signature of the
log method should/might be changed)
- beeing forced to totally order all types of messages can
be difficult. You may want e.g. to log 'TimeoutMessages'
no matter what the current integer threshold might be.
why not something like: loginstance.accept(TimeoutMessage)
- Message instances can defer the *construction* of a string
until it is really needed. (see my other posting for a code
example). This is more effective if you choose to ignore
certain messages. This has *nothing* to do with formatting.
- customized messages are powerful and allow more advanced
filtering than with strings, especially for large apps.
a connection-logger could choose to ignore a
TimeoutMessage(socket) based on the target address of the
socket. doing this with strings is hard (and perlish:-)
- a SocketMessage-class may hold a weakref-list of sockets allowing
to log 'sock<1>', 'sock<2>' instead of addresses which are
hard to read. stuff like this is *very* convenient. Again
there is hardly any performance penalty if SocketMessages
Maybe the categorization features of the logging
API make up for some of the (relative) inflexibilities of
But what do you really gain by restricting a message
to a (string,integer) taking my arguments into account?