Re: Extending Logger

[Matimus]

Yes but in the other hand :http://docs.python.org/library/loggi...logger-objects

"Note that Loggers are never instantiated directly, but always through
the module-level function logging.getLogg er(name)."

That is part of the power of the logging module. If you ask for a
logger of the same name in two different place you will get the same
object. That way you don't have to pass the logger instances around,
and it always has the same properties (same handlers attached, same
level, etc.). If you want to add functionality you getLoggerClass,
inherit from that, then setLoggerClass, and use the regular logging
facilities to instantiate them.

The only limitation here is that you can't change the constructor.
Well, it isn't useful to change the constructor. You can add a method
that does the same thing.

I can't help but feel that if you have a problem with this, you simply
aren't using the Logging module the way it was meant to be used.

Matt

[polettog@gmail.com]

Re: Extending Logger

On Nov 7, 8:23 pm, Matimus <mccre...@gmail .comwrote:

Yes but in the other hand :http://docs.python.org/library/loggi...logger-objects
"Note that Loggers are never instantiated directly, but always through
the module-level function logging.getLogg er(name)."

>
That is part of the power of the logging module. If you ask for a
logger of the same name in two different place you will get the same
object. That way you don't have to pass the logger instances around,
and it always has the same properties (same handlers attached, same
level, etc.). If you want to add functionality you getLoggerClass,
inherit from that, then setLoggerClass, and use the regular logging
facilities to instantiate them.
>
The only limitation here is that you can't change the constructor.
Well, it isn't useful to change the constructor. You can add a method
that does the same thing.
>
I can't help but feel that if you have a problem with this, you simply
aren't using the Logging module the way it was meant to be used.
>
Matt

Thanks for your answers.
Well, I just wanted to point out that there's maybe a little problem
in the design of Logger since we don't have to know what's the Logger
constructor, except when inheriting from it (for instance, the
documentation doesn't give the parameters of Logger.__init__ ()). So, i
thought Logger wasn't really made to be inherited.

Also, i dislike the fact that loggers are global, and that we have to
use setLoggerClass before any call to getLogger : we can't be sure
that no logger have been created before. These kind of issues are well
known in C programs, when some global stuff need to be initiated, we
don't know how it's done and when, so the clean way is usually to have
an object created/destroyed manually and passed in parameters of
functions needing it.
Yes i know it's more convinient to get rid of passing the object
through all the code and for most people it's an interesting feature,
but to me it could have been better if using a global system was not
mandatory.

So now, i feel shared between the following possibilities :
1) Using a global logger, setting the class in the beginning of my
program (this may not be easy), using getLogger in the different parts
of my application
2) Using a global logger, not subclassing Logger, stay with the
standard methods and deal with the Handlers/Formatters to customize
some of what i want to do. After all, i only wanted to add convenience
methods to log errors of specific type.
3) Making a class that handles internally a global logger (whose name
is not to be known by the class user) and only create methods that i
need.
4) Same thing but with a class that implements all the Logger methods
(is this called "duck typing"?), so all my code could work with a
standard Logger
5) Forget the logging module, it's not te be used the way i want to
use it