[Python-Dev] PEP282 and the warnings framework

holger krekel pyth@devel.trillke.net
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
  are ignored.

Maybe the categorization features of the logging 
API make up for some of the (relative) inflexibilities of 
string/integer messages. 

But what do you really gain by restricting a message 
to a (string,integer) taking my arguments into account? 

regards,

    holger