Changes between Version 2 and Version 3 of TwistedLogging


Ignore:
Timestamp:
12/04/2006 08:34:07 PM (8 years ago)
Author:
exarkun
Comment:

fix some more wiki markup

Legend:

Unmodified
Added
Removed
Modified
  • TwistedLogging

    v2 v3  
    1414    1. No support for system metrics.  Because you can't log structured data, there's no way to install an observer which watches all events of a particular type and aggregates numerical data associated with them as the server is running. 
    1515    1. Hard to avoid string formatting work when unnecessary.  Ideally, systems which want to log a lot in debug mode and log only a little in production mode ought to be able to call the logging system with a format string and some description data, and then let it decide whether to do work or not.  However, with the "logging" module, you need to do most of the string formatting work up front, passing a complete message to the system, rather than a message format and some arguments to populate it with in the event that it should actually be logged. (Some people have complained to me that it actually *does* support structured data, considering that you can subclass LogRecord, but that does not look well supported and LogRecord itself is ugly.  8 attributes for every log message?  name, lvl, pathname, lineno, msg, args, exc_info ...?  That looks dangerously introspective to me.  Also, LogRecord could easily have been a dict rather than an instance; logging tends to be HIGHLY performance critical so little details like that bother me.) 
    16   1. Hard-coded log levels.  This is a more personal objection, but I've never seen a sensible way to distinguish between messages which should be "INFO" and which should be "DEBUG".  It seems to boil down to personal style differences, which means that in the same application you will get different levels of verbosity from the logging system depending on which programmer was coding.  Also, I dislike the workflow that a "DEBUG" loglevel encourages.  Information that you need while initially debugging an application should be *removed*; leaving it in is like (although obviously not as bad as) releasing your code 
    17 with 'pdb.set_trace()' calls in it.  Our current logging system is simple and elegant.  It needs to be better documented, and perhaps broken down into a hierarchy to avoid spurious notifications (for slightly more efficiency). 
     16  1. Hard-coded log levels.  This is a more personal objection, but I've never seen a sensible way to distinguish between messages which should be "INFO" and which should be "DEBUG".  It seems to boil down to personal style differences, which means that in the same application you will get different levels of verbosity from the logging system depending on which programmer was coding.  Also, I dislike the workflow that a "DEBUG" loglevel encourages.  Information that you need while initially debugging an application should be *removed*; leaving it in is like (although obviously not as bad as) releasing your code with 'pdb.set_trace()' calls in it.  Our current logging system is simple and elegant.  It needs to be better documented, and perhaps broken down into a hierarchy to avoid spurious notifications (for slightly more efficiency). 
    1817 
    1918=== But Isn't Anything About Logging Good? ===