Hi Ginnie,
I think the document is looking fantastic. The detail has helped me
understand the logging module.
My remaining concern is with the API for init_logger and add_handler.
I had to read ahead all the way down to use cases to fully understand
the "handler" argument. It appears that a string or constant will be
mapped to a handler type by the init_logger call, and instantiated using
args also passed into init_logger. This explains Sarah's desire to have
arbitrary arguments passed in, but even with that, it sounds overly
restrictive. Why not instantiate the handler, and then pass in the
handler reference to init_logger?
e.g.
handler = logging.FileHandler(...)
logging.init_logger(app_name, handler, logging.INFO)
In this way, any logging handler, even handlers which are not directly
defined in the logging module (e.g., an application specific subclass)
can be passed in, and the init_logger function doesn't have to worry
about understanding those things.
With intelligent defaults for keyword arguments for handlers, this can
even be reduced further to something as simple as:
logging.init_logger(app_name, logging.Filehandler()).
Similarly, with init_handler - why not call it "add_handler"? Let the
consumer pass in a constructed handler, and have the add_handler code
handle any additional registration, such as setting up the proper
formatting, logging level, and the like. Done properly, this would be
far more flexible, yet maintain simplicity for the default cases. If
defaults for kwargs is not sufficient, provide a 'generator' or
'factory' function for those specific classes. For example, if the HTTP
defaults require logging module context, then a function such as:
logging.generate_http_handler(host, url, ...)
If the argument is complexity - I argue that it's more complex to ask
the consumers to construct the **kwargs object, instead of the more
natural method of simply instantiating the desired handler instance.
Use cases:
Pseudo code for log_messages: I know it's just sample code, but, if log
levels mapped to integers in the same way Python's logging module does,
then it's a much simpler task to do something like:
def log_message(...):
for handler in self.handlers:
handler.log(self.logging_level, message, ...)
Thanks,
Keith
On 03/12/10 04:39 PM, Virginia Wray wrote:
> Hi -
>
> I've posted the second draft of the Logging design doc at:
>
> http://hub.opensolaris.org/bin/view/Project+caiman/Logging
>
> Select Loggingv1.2.pdf
>
> Please provide feedback by March 24, 2010.
>
> thanks,
>
