The logging package should be modified in a way which
would let users call the setLoggerClass API, and then
consistently get loggers only from that class. 

In the logging package as it is today, the root logger
will always be a logging.Logger instance, and not the
new class specified in the call to setLoggerClass.
These semantics are not clear.

Logged In: YES 
user_id=308438

Can you please explain your use case? Why does the package
have to be modified in that way? Why do you need to be able
to have the root logger be creatable from a custom class?

Logged In: YES 
user_id=1340892

This is an example logger class I would like to use:

class PatchedLogger(logging.Logger):
    def __init__(self, name, *patches):
        logging.Logger.__init__(self, name)
        self.patches = patches
    def handle(self, record):
        #copied from the actual Logger implementation
        if (not self.disabled) and self.filter(record):
            for patch in self.patches:
                patch(record)
            self.callHandlers(record)

And an example "patch":
def EnableTrace(record):
    """
    adds the %(function)s for logging records
    """
    function_name = _get_function_name(inspect.stack()[4])
    record.function = function_name

Logged In: YES 
user_id=308438

OK - I'm part way through implementing a change whereby the
function name is available through the base logging
functionality - the findCaller() implementation in CVS
currently gets the function name, but I have not yet
implemented the part which puts it into the LogRecord. So
this particular patch of yours will soon not be necessary.

Also note that you can also redefine the record-making
function - but I am currently thinking of how to make this
part of the system better, as it is a little untidy at the
moment. The objective is to make it easy to add whatever you
want to the LogRecord __dict__ which can later be used in
the formatted output.

Logged In: YES 
user_id=1340892

That sounds fine.

The only thing I think is important is that it'll be
possible to add fields to the LogRecord in the period of
time between its creation and its "emitting". That will let
users add any behavior desired to the logging mechanism.

In addition, since setLoggerClass is obviously not intended
for users, it should be prefixed with an underscore or made
"pseudo private"... its otherwise confusing.

Logged In: YES 
user_id=308438

Recent checkins to CVS cater for adding user-defined
attributes to a LogRecord, and the function name is also
available in the LogRecord.