Re: [Python-markdown-discuss] Ticket 18: DEBUG log setting

[Michael B. <mi...@zz...>]

On Oct 6, 2008, at 2:31 PM, Waylan Limberg wrote:

> Mike thanks for the bug report on Ticket 18 [1]. I'm copying the list
> with my response.
>
>> markdown.py has a hardcoded logging setting of DEBUG,
>> which allows all DEBUG messages to go out to all
>> configured handlers. There's then a comment which says
>> something to the effect of "this is restricted by handlers
>> later". I'd like to propose that this is the incorrect usage
>> of logging
>
> Actually, based on my testing the current behavior is correct. Suppose
> we set the logger to CRITICAL. Then, someone adds a handler (perhaps
> that writes to a log file) set to DEBUG. Because the logger only
> allows CRITICAL messages through, the handler would never receive
> anything less than CRITICAL even though its set to DEBUG. That's
> unacceptable - and why the logger is wide open and the handlers later
> restrict the level.
>
> The intention is that users would set (and/or remove) handlers and set
> the level for each handler as they need. In fact, we realize that the
> StreamHandler will break in some web server environments (it's
> indented for command line use) and may need to be removed/replaced
> with a handler appropriate for your system. That's why we recently
> adopted use of  Python's logger rather than our own old inflexible
> home-grown solution. It's much easier to override handlers than
> monkeypatch the old system.

The source comments indicate that this is the intention, but using  
handlers to filter log messages has the effect that *all* loggers, of  
all names, are filtered equally.  I dont see how this could ever be  
useful in an environment that has other loggers present besides  
"MARKDOWN".    Using it this way, there is simply no way for other  
libraries to have their logging output altered independently - you are  
controlling the water in the bathtub by turning the spigot on the  
central water main supplying the whole building, instead of the  
individual faucet.   You're not really getting any benefit from using  
logging in this way.   Theres a diagram at http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.html#1.1 
  which might make this more visible (although both pep-282 and the  
java spec don't enunciate the distinction between "library" and  
"application environment").

> Actually I envisioned something very similar, except altering the
> *handler* attached to the logger, not the logger itself. Perhaps it's
> not the most convenient (in that it doesn't integrate with your
> environment's settings file), but a solution that will work in a
> variety of different situations is certainly welcome. I'm not
> personally familiar with Pylons and/or Paste, but would certainly like
> to see easy use of markdown in such a context. At the same time,
> markdown needs to continue to work as it does now from the command
> line as well as in other environments.

its simple.  markdown uses the "MARKDOWN" logger, and sends messages  
out using whichever levels it likes; i.e. logger.info(),  
logger.debug(), etc.  But it does *not* within markdown.py's module  
initialization set the actual log level or configure any handlers.   
This is because markdown.py in total is not a commandline application,  
its first and foremost a library - it should not assume awareness  
about the environment in which it runs, and especially not attempt to  
alter its runtime environment (which setting log levels and  
configuring handlers is).   logging was meant to be used in such a way  
that you don't actually access elements of the module itself - the  
getLogger() call and resulting object is the only interaction.

If you have a specific function that assumes a certain application  
environment and requires logging, that's fine - configure the handlers  
and logging levels there.  The specific settings of DEBUG and  
streamhandler are appropriate in this case to when one uses the  
markdownFromFile function.  *That* is where the environment-specific  
logger should be configured, since markdownFromFile assumes a  
particular environment; markdown.markdown() should not.  A global flag  
"loggingConfigured" may be used to detect that markdownFromFile has  
already been called to prevent the same configuration from being  
called twice.

In SQLAlchemy, we have a flag called "echo=True" which also sets up an  
environment-specific logging configuration.  But the point is, if the  
user does not set echo=True, SQLA doesn't set up any log configuration  
so that it's compatible with the rest of the world.  We also use a  
module-level flag to determine, when an echo=True is detected, if  
we've already set our "hardwired" logging environment.   We don't  
configure any kind of environmental log settings by default.

The Python logging module is modeled extremely closely to the Java  
log4j library which is the standard logger used by virtually all Java  
libraries.  The practices I'm advising here are the  same used within  
the Java community, which is how "logging" was meant to be used (PEP  
282 references the java spec and is largely copied verbatim).    
Otherwise, every Java library I imported into my application would be  
setting all kinds of log levels without my intervention, ignoring  
existing settings.