Hi All, Is zLOG deprecated? If not, it should be... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Is zLOG deprecated?
If not, it should be...
+10 zLOG/__init__.py says: Note: This module exists only for backward compatibility. Any new code for Zope 2.8 and newer should use the logging module from Python's standard library directly. zLOG is only an API shim to map existing use of zLOG onto the standard logging API. That means we could deprecate it even in Zope 2.9, using zLOG has already been discouraged in Zope 2.8. I'm not sure if the differences in logging levels will be important to backward compatability. ZODB/loglevels.py explains the differences:: # In the days of zLOG, there were 7 standard log levels, and ZODB/ZEO used # all of them. Here's how they map to the logging package's 5 standard # levels: # # zLOG logging # ------------- --------------- # PANIC (300) FATAL, CRITICAL (50) # ERROR (200) ERROR (40) # WARNING, PROBLEM (100) WARN (30) # INFO (0) INFO (20) # BLATHER (-100) none -- defined here as BLATHER (15) # DEBUG (-200) DEBUG (10) # TRACE (-300) none -- defined here as TRACE (5) # # TRACE is used by ZEO for extremely verbose trace output, enabled only # when chasing bottom-level communications bugs. It really should be at # a lower level than DEBUG. # # BLATHER is a harder call, and various instances could probably be folded # into INFO or DEBUG without real harm. Philipp
Philipp von Weitershausen wrote:
If not, it should be...
+10
Yeah, me too! Hence why I was asking ;-)
That means we could deprecate it even in Zope 2.9, using zLOG has already been discouraged in Zope 2.8.
Cool, Andreas, can you make it start emitting deprecation warnings? (if you do, lemme know and I'll go grep the Zope 2 source and try and eradicate any remaining zLOG)
I'm not sure if the differences in logging levels will be important to backward compatability.
I _know_ they won't ;-)
ZODB/loglevels.py explains the differences::
# In the days of zLOG, there were 7 standard log levels, and ZODB/ZEO used # all of them. Here's how they map to the logging package's 5 standard # levels: # # zLOG logging # ------------- --------------- # PANIC (300) FATAL, CRITICAL (50) # ERROR (200) ERROR (40) # WARNING, PROBLEM (100) WARN (30) # INFO (0) INFO (20) # BLATHER (-100) none -- defined here as BLATHER (15) # DEBUG (-200) DEBUG (10)
imnsho, blather and debug are the wrong way round. blather should go away completely, it's a stupid name anyway :-( cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
# In the days of zLOG, there were 7 standard log levels, and ZODB/ZEO used # all of them. Here's how they map to the logging package's 5 standard # levels: # # zLOG logging # ------------- --------------- # PANIC (300) FATAL, CRITICAL (50) # ERROR (200) ERROR (40) # WARNING, PROBLEM (100) WARN (30) # INFO (0) INFO (20) # BLATHER (-100) none -- defined here as BLATHER (15) # DEBUG (-200) DEBUG (10)
imnsho, blather and debug are the wrong way round. blather should go away completely, it's a stupid name anyway :-(
Just because you don't see the use in something doesn't mean it has to go away. In my book BLATHER is used for "verbose INFO" and is different than DEBUG and TRACE (both levels are useful too). INFO and BLATHER are for the administrator. DEBUG and TRACE are for the developer. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
We probably want an "ALL" level as well which would map to the "NOTSET" of the Python logging code and log everything. Florent, I don't see a TRACE level in this list. Did you think one was needed? On Mon, 5 Dec 2005, Florent Guillaume wrote:
Chris Withers wrote:
# In the days of zLOG, there were 7 standard log levels, and ZODB/ZEO used # all of them. Here's how they map to the logging package's 5 standard # levels: # # zLOG logging # ------------- --------------- # PANIC (300) FATAL, CRITICAL (50) # ERROR (200) ERROR (40) # WARNING, PROBLEM (100) WARN (30) # INFO (0) INFO (20) # BLATHER (-100) none -- defined here as BLATHER (15) # DEBUG (-200) DEBUG (10)
imnsho, blather and debug are the wrong way round. blather should go away completely, it's a stupid name anyway :-(
Just because you don't see the use in something doesn't mean it has to go away.
In my book BLATHER is used for "verbose INFO" and is different than DEBUG and TRACE (both levels are useful too). INFO and BLATHER are for the administrator. DEBUG and TRACE are for the developer.
Florent
--
[Dennis Allison]
We probably want an "ALL" level as well which would map to the "NOTSET" of the Python logging code and log everything.
Why not call it NOTSET? Then you already have it ;-) Or forget it -- TRACE gets everything anyway.
Florent, I don't see a TRACE level in this list. Did you think one was needed?
See Florent's original message; Chris chopped TRACE away in his reply. Also note that the code Florent pointed at is part of ZODB, not part of Zope. Zope shouldn't use it directly. Growing its own copy would be OK, or refactoring so that ZODB and Zope both get it from a shared new mini-project.
Tim Peters wrote:
[Dennis Allison]
We probably want an "ALL" level as well which would map to the "NOTSET" of the Python logging code and log everything.
Why not call it NOTSET? Then you already have it ;-) Or forget it -- TRACE gets everything anyway.
Yeah, what he said ;-)
Also note that the code Florent pointed at is part of ZODB, not part of Zope. Zope shouldn't use it directly. Growing its own copy would be OK, or refactoring so that ZODB and Zope both get it from a shared new mini-project.
Sorry, which code are we talking about here? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
[Tim Peters]
Also note that the code Florent pointed at is part of ZODB, not part of Zope. Zope shouldn't use it directly. Growing its own copy would be OK, or refactoring so that ZODB and Zope both get it from a shared new mini-project.
[Chris Withers]
Sorry, which code are we talking about here?
Sorry, it wasn't Florent, it was Philipp; you replied to it: <http://mail.zope.org/pipermail/zope-dev/2005-December/026039.html> As he says there, the comment block was taken from ZODB/loglevels.py, which (besides just documenting this mess) implements TRACE and BLATHER levels for ZODB's use.
Florent Guillaume wrote:
Just because you don't see the use in something doesn't mean it has to go away.
There's nothing to stop you defining your own log levels with the python logging module. I regularly (eg: MailingLogger) define a report level that is 1 above INFO.
In my book BLATHER is used for "verbose INFO" and is different than DEBUG and TRACE (both levels are useful too). INFO and BLATHER are for the administrator. DEBUG and TRACE are for the developer.
Well, I don't think has been consistently applied to the whole source tree ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Philipp von Weitershausen wrote:
If not, it should be...
+10
Yeah, me too! Hence why I was asking ;-)
That means we could deprecate it even in Zope 2.9, using zLOG has already been discouraged in Zope 2.8.
Cool, Andreas, can you make it start emitting deprecation warnings? (if you do, lemme know and I'll go grep the Zope 2 source and try and eradicate any remaining zLOG)
This would probably best be handled by one person, so if you are willing to do all the grepping and updating, making zLOG deprecated would just be a minor operation :). In zLOG.LOG one would call warnings.warn() and the custom zLOG logging level constants could be wrapped in a deprecation warnings (zope.deprecation.deprecate) telling people where to import the level from now (either logging or ZODB.loglevels).
I'm not sure if the differences in logging levels will be important to backward compatability.
I _know_ they won't ;-)
If you say so :)
ZODB/loglevels.py explains the differences::
# In the days of zLOG, there were 7 standard log levels, and ZODB/ZEO used # all of them. Here's how they map to the logging package's 5 standard # levels: # # zLOG logging # ------------- --------------- # PANIC (300) FATAL, CRITICAL (50) # ERROR (200) ERROR (40) # WARNING, PROBLEM (100) WARN (30) # INFO (0) INFO (20) # BLATHER (-100) none -- defined here as BLATHER (15) # DEBUG (-200) DEBUG (10)
imnsho, blather and debug are the wrong way round. blather should go away completely, it's a stupid name anyway :-(
Well, stupid or not, the order in which BLATHER and DEBUG are should be preserved, even if it might not make sense. Question is if we actually need BLATHER in the future. For all I care we could rip it out. Philipp ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Philipp von Weitershausen wrote:
This would probably best be handled by one person, so if you are willing to do all the grepping and updating, making zLOG deprecated would just be a minor operation :).
...but one i don't know how to perform. What code would I insert and where? I'm happy to sign up for this, but can't promise when it'll happen...
In zLOG.LOG one would call warnings.warn()
Ah, okay :-)
and the custom zLOG logging level constants could be wrapped in a deprecation warnings (zope.deprecation.deprecate)
How would I do this? Can you give me an example?
Well, stupid or not, the order in which BLATHER and DEBUG are should be preserved, even if it might not make sense. Question is if we actually need BLATHER in the future. For all I care we could rip it out.
Likewise. Florent's the only person who seems to care about these arcane names ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Philipp von Weitershausen wrote:
This would probably best be handled by one person, so if you are willing to do all the grepping and updating, making zLOG deprecated would just be a minor operation :).
...but one i don't know how to perform. What code would I insert and where?
See below :). Of course, you don't have to deprecate zLOG instantly. Removing all of its references could already be done now.
I'm happy to sign up for this, but can't promise when it'll happen...
So let's schedule it for Zope 2.10 then :).
In zLOG.LOG one would call warnings.warn()
Ah, okay :-)
A typical call to warnings.warn() looks like this:: warnings.warn("This is deprecated, dude", DeprecationWarning, stacklevel=2) The stacklevel=2 is important because the deprecation warning "traceback" wouldn't point to the offending code otherwise.
and the custom zLOG logging level constants could be wrapped in a deprecation warnings (zope.deprecation.deprecate)
How would I do this? Can you give me an example?
Use the doctests, Luke :). Anyway, here's an example: http://svn.zope.org/Zope3/trunk/src/zope/i18nmessageid/__init__.py?rev=39525... It shows how to wrap stuff in deprecation proxies using zope.deprecation.deprecate(). Then any access to these objects (e.g. importing) will trigger a warning. It also demonstrates how to temporarily turn off those deprecation warnings, for example when you're using deprecated stuff for internal use, such as still supporting old import locations (as in this case). Philipp ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Philipp von Weitershausen wrote:
See below :). Of course, you don't have to deprecate zLOG instantly.
How else do you stop people still following the old patterns ;-)
I'm happy to sign up for this, but can't promise when it'll happen...
So let's schedule it for Zope 2.10 then :).
OK, I promise, I will try, even if only to stop Jens whining ;-)
and the custom zLOG logging level constants could be wrapped in a deprecation warnings (zope.deprecation.deprecate)
How would I do this? Can you give me an example?
Use the doctests, Luke :). Anyway, here's an example: http://svn.zope.org/Zope3/trunk/src/zope/i18nmessageid/__init__.py?rev=39525...
It shows how to wrap stuff in deprecation proxies using zope.deprecation.deprecate(). Then any access to these objects (e.g. importing) will trigger a warning. It also demonstrates how to temporarily turn off those deprecation warnings, for example when you're using deprecated stuff for internal use, such as still supporting old import locations (as in this case).
Great, that's the bit I was looking for... OK, I will try, but I can't make any definite problems. I'll take a branch of the trunk and get going on it, but if anyone else is thinking of adding new code that uses zLOG, please don't ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (5)
-
Chris Withers -
Dennis Allison -
Florent Guillaume -
Philipp von Weitershausen -
Tim Peters