Chris Withers wrote:
1.) It would be nice to have a policy for Zope. If the Zope core
officially supports the BLATHER level (not just in the deprecated zLOG
module) I'm fine with using it in GenericSetup as well.
It doesn't, ZODB has a mapping for it but it's a stupid name left over
from before the same timeframe as STUPID_LOGGER and some of the wacky
error messages that ZServer used to spit out. I really want it to die :-(
It doesn't right now, but AFAIR the discussion on zope-dev ended without
a clear result. The question if BLATHER should die isn't CMF specific in
any way, so I don't want to discuss it on this list.
2.) So far IWriteLogger just defines methods that are also used by the
python logging Logger. If we add a blather method we can no longer use
the python logger as a replacement.
Hmmm, this sounds odd. Why does IWriteLogger even exist if it just
mirrors the python logging interface?
Feel free to contribute a patch if you think this could be implemented
in a cleaner way. I don't have the time to figure out how to use the
Python logger for the reports created by the setup tool. The current
implementation is a wrapper around the Python logger which adds a copy
of all messages to the _messages list of the setup context.
3.) I don't think all messages should have the same logging level.
E.g. if there are problems that will cause broken setups WARNING might
No, .error is what you want here.
No, WARNING is what I want here.
.warning is for things that are problems but which don't result in
By 'broken setups' I meant e.g. if you loose some catalog indexes on
export/import because no handler exists for those index classes. This is
a problem you should know about, but maybe you don't care or you fix
that by hand.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests