[ python-Feature Requests-1474577 ] feature requests for logging lib

[SourceForge.net]

Feature Requests item #1474577, was opened at 2006-04-22 09:50
Message generated for change (Settings changed) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Pending
>Resolution: Invalid
Priority: 5
Submitted By: blaize rhodes (blaize)
Assigned to: Vinay Sajip (vsajip)
Summary: feature requests for logging lib

Initial Comment:


The logger module interface is a bit broken, I reckon.
 My problems specifically are:
 
	i) It's hard to get access to the LogRecord classes
for customization.
	ii) the semantics of the debug, log, info, etc calls
is a bit strange/confusing...



Here are my proposed fixes:

a)  Add a method 
   Logger.setLogRecordClass( myLogRecordSubClass )

which sets the class that is instantiated in the
makeRecord() fn/method (yes there are two of them).

This would make customizing the LogRecord easier... 
Otherwise (I believe) in order to subclass the
LogRecord you also have to overload the Logger and
possibly the root makeRecord() function as well?  This
bloke's writen up his approach to this (it's doable but
not as nice as it should be).
 
http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html

Another problem is that LogRecords are instantiated in
Logger._log so it's difficult to customize __init__
behaviour for the LogRecord (and I argue that this is a
useful thing)..  

b) A second problem is that the semantics of the log,
info, debug, etc fns is a bit broken.  Currently the
defn looks like this:

  def debug(self, msg, *args, **kwargs):

this suggests to me that a call like this is OK...

  logger.debug("here we go %(foo)s", foo = 'bar')

but it's not.  This is discussed further here...

http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881

Instead kwargs are used for customizing the behaviour
of the debug method (e.g. exc_info, and extra).  This
seems i) a bit incongrous with its definition and
therefore confusing, and ii) a bit of a hack (it's not
completely insane though when you think about what's
happening under the hood).  Instead I propose using a
couple of calls along the lines of printf/fprintf.  In
my world we'd have a simple printf-style function... 

  def debug(self, msg, *args):  

and a more complex, more easily customizable
fprintf-style one

  def x_debug(self, log_record, msg, *args):  

In these calls *args is a valid argument for the string
formatting operator %, either a tuple of the right
length or a dictionary.  Any customization of the
behaviour of the system can be done (using keyword args
if you wish) in the log_record initializer (an example
will follow).

(Having said that perhaps we can check whether the
first arg to the new simple debug() is a logrecord and
if it is call the (hidden) extended version - that's
more pythonic I imagine)


c) This is not so much a feature request but a
motivating mode of operation that I'd like to be able
to use...

Currently you can set up log filters.  What you can
filter is largely based on what information appears in
the log record.  It'd be nice to filter messages based
on metadata  that you add at log time (i.e. in the
logger.debug(...) method).  Currently it's quite
painfull to set this up.  This is because we can't
customize the initialization of the log_record.  The
call structure in ii) above allows us to setup nice
filtering mechanisms
eg..

class GUIFilter:
   "A filter that only lets messges with gui tags
through."""
	def filter(self, log_record):
	    return hasattr(log_record, 'gui')

# set up a log, and a handler...
log = logging.getLogger(..)
file_handler = FileHandler(..)
log.addHandler(file_handler)
gui_msg_bar_handler = StreamHandler(..)
log.addHandler(gui_msg_bar_handler)
gui_msg_bar_handler.addFilter(GUIFilter())

# msg only goes to the file_handler
log.debug("here we go %s", "here's an arg")  

# msg goes to the file_handler and to the gui_handler.
log.x_debug(LogRecord(gui=True), "what you just tried
to do didn't work %s", "fool")


Change a) could be made with no backward compatability
problems (I can see), change b) could be made without
probs if you didn't overload the existing logging
methods with the new ones, and then deprecate the
existing ones  (though what you'd call the new fns I
don't know).

That said I quite like the logger lib and I use it. 
It's a lot better than anything I would have thought up.


cheers
    blaize



----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2006-05-02 09:11

Message:
Logged In: YES 
user_id=308438

Why does the recent introduction of the 'extra' keyword
argument, meant to allow easily adding extra attributes to
the LogRecord, not meet your use cases? The LogRecord is
meant to be just a handy container and not have much logic
(e.g. it needs to be serialised as XML, pickle etc.); why do
you need to customise LogRecord.__init__? I didn't see an
actual argument above for doing this, please point it out.

It's also the case that the msg argument passed to a logging
call need not be a string; it can be an arbitrary object on
which str() is called at message formatting time to get the
actual format string. So a custom object defining __str__
can return a customised message string.

Perhaps I'm not seeing the use case you have in sufficient
detail to understand why existing functionality does not
meet your needs; please feel free to follow up with more
detailed info.



----------------------------------------------------------------------

Comment By: blaize rhodes (blaize)
Date: 2006-04-22 09:56

Message:
Logged In: YES 
user_id=264689



For readability put an "if __name__ == '__main__':" above the 

# set up a log, and a handler...

line.  Sorry I didn't realize all my whitespace would get
eaten rendering the code ambiguous.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470