Menu
▾
▴
python-markdown-discuss
|
From: Waylan L. <wa...@gm...> - 2008-10-06 18:35:40
|
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 workaround for now is that you have to hardcode a call
> to "logging.getLogger("MARKDOWN").setLevel(logging.WARN)"
> to silence the MARKDOWN logger in your application code
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.
If anyone has any suggestions and/or solutions I'm all ears.
[1]: http://www.freewisdom.org/projects/python-markdown/Tickets/000018
--
----
Waylan Limberg
wa...@gm...
|
|
From: Yuri T. <qar...@gm...> - 2008-10-06 19:16:47
|
What about something like this:
if logger.level = logging.NOTSET :
logger.setLevel(DEBUG)
This way the caller can set the logging level before importing markdown:
>>> import logging
>>> logging.getLogger("MARKDOWN").setLevel(logging.critical)
>>> import markdown
>>> markdown.logger.level
<function critical at 0xb7c19a3c>
(I committed this change as 2c6a74f, in case you want to look at it.
But feel free to revert if we come up with a better solution.)
- yuri
On Mon, Oct 6, 2008 at 11:31 AM, Waylan Limberg <wa...@gm...> 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 workaround for now is that you have to hardcode a call
>> to "logging.getLogger("MARKDOWN").setLevel(logging.WARN)"
>> to silence the MARKDOWN logger in your application code
>
> 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.
>
> If anyone has any suggestions and/or solutions I'm all ears.
>
> [1]: http://www.freewisdom.org/projects/python-markdown/Tickets/000018
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>
--
http://sputnik.freewisdom.org/
|
|
From: Waylan L. <wa...@gm...> - 2008-10-06 19:48:08
|
On Mon, Oct 6, 2008 at 3:02 PM, Michael Bayer <mi...@zz...> wrote: [snip] > 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 This is were things seem to fall apart. I agree here, however, whenever I've suggested changes of this type, I always get a response from Yuri that indicates he sees markdown first and foremost as a commandline script and second as a library. Perhaps we've gotten our wires crossed on this and that's not how he sees it - but I'm pretty sure he at least leans more in that direction that I do. Correct me if I'm wrong. > - 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. I like this suggestion. Although I'm not so sure the "loggingConfigured" flag is necessary. Thanks for your input. I'll play around with this and see what I can come up with. Unfortunately, I'm a little busy right now, so it may be a few weeks. -- ---- Waylan Limberg wa...@gm... |
|
From: Yuri T. <yu...@cs...> - 2008-10-06 21:03:28
|
>> 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
>
> This is were things seem to fall apart. I agree here, however,
> whenever I've suggested changes of this type, I always get a response
> from Yuri that indicates he sees markdown first and foremost as a
> commandline script and second as a library. Perhaps we've gotten our
> wires crossed on this and that's not how he sees it - but I'm pretty
> sure he at least leans more in that direction that I do. Correct me if
> I'm wrong.
Actually, if I personally had to choose between markdown.py as a
library and as a command line application, I would probably choose the
library. (If you just want a command line tool, you have more
alternatives, including Markdown.pl.) However, I've always meant it
to work as both, and in this case I don't think we have a conflict
between them. As far as command line use goes, we can just configure
the logger inside main().
So, the question is: from the point of view of library users, does it
make more sense to setup logging levels? Or should we just leave them
as undefined? One potential compromise would be to move all logging
setup into a function, leaving the library caller an option of calling
it:
import markdown
markdown.setup_logging()
- yuri
--
http://sputnik.freewisdom.org/
|
|
From: Michael B. <mi...@zz...> - 2008-10-06 20:45:01
|
On Oct 6, 2008, at 4:27 PM, Yuri Takhteyev wrote:
>>>
> So, the question is: from the point of view of library users, does it
> make more sense to setup logging levels? Or should we just leave them
> as undefined? One potential compromise would be to move all logging
> setup into a function, leaving the library caller an option of calling
> it:
>
> import markdown
> markdown.setup_logging()
the "library" point of view would leave logging levels and handlers
undefined. libraries just call
logging.getLogger('MARKDOWN').debug("my message"), and possibly
isEnabledFor() (although that call is known to be slow), and the
configuration of the "MARKDOWN" logger is left to external actors.
|
|
From: Michael B. <mi...@zz...> - 2008-10-06 23:06:34
|
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. |
|
From: Yuri T. <qar...@gm...> - 2008-10-06 23:42:46
|
> the "library" point of view would leave logging levels and handlers
> undefined. libraries just call logging.getLogger('MARKDOWN').debug("my
> message"), and possibly isEnabledFor() (although that call is known to be
> slow), and the configuration of the "MARKDOWN" logger is left to external
> actors.
Ok. And thanks for your clarification in your previous message, which
for some reason landed in my inbox only after I responded to Waylan's
response to your response.
So: I'll move the logging configuration into main(), define a function
getLogger() as a shorthand for logging.getLogger('MARKDOWN'), and do
logging through it. We won't configure logging except when getting
called from the command line. Does this sound like the right plan?
- yuri
--
http://sputnik.freewisdom.org/
|
|
From: Michael B. <mi...@zz...> - 2008-10-07 04:19:20
|
On Oct 6, 2008, at 7:41 PM, Yuri Takhteyev wrote:
>> the "library" point of view would leave logging levels and handlers
>> undefined. libraries just call
>> logging.getLogger('MARKDOWN').debug("my
>> message"), and possibly isEnabledFor() (although that call is known
>> to be
>> slow), and the configuration of the "MARKDOWN" logger is left to
>> external
>> actors.
>
> Ok. And thanks for your clarification in your previous message, which
> for some reason landed in my inbox only after I responded to Waylan's
> response to your response.
>
> So: I'll move the logging configuration into main(), define a function
> getLogger() as a shorthand for logging.getLogger('MARKDOWN'), and do
> logging through it. We won't configure logging except when getting
> called from the command line. Does this sound like the right plan?
sounds right ! thanks
|
|
From: Yuri T. <qar...@gm...> - 2008-10-07 08:48:55
|
Fixed with 6d719bd (http://gitorious.org/projects/python-markdown/repos/mainline/commits/6d719bd). - yuri > sounds right ! thanks > -- http://sputnik.freewisdom.org/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X