How many people would get indignant if I checked in a fix that undeprecated zLOG? Removing the API seems silly, since its just a wrapper around the logging module now anyway. - C
Chris McDonough wrote:
How many people would get indignant if I checked in a fix that undeprecated zLOG? Removing the API seems silly, since its just a wrapper around the logging module now anyway.
±0 I've become indifferent. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
--On 1. Februar 2007 11:01:56 -0500 Chris McDonough <chrism@plope.com> wrote:
How many people would get indignant if I checked in a fix that undeprecated zLOG? Removing the API seems silly, since its just a wrapper around the logging module now anyway.
-0. We could make zLOG available as egg or as downloadable product. Andreas
On Feb 1, 2007, at 11:59 AM, Andreas Jung wrote:
--On 1. Februar 2007 11:01:56 -0500 Chris McDonough <chrism@plope.com> wrote:
How many people would get indignant if I checked in a fix that undeprecated zLOG? Removing the API seems silly, since its just a wrapper around the logging module now anyway.
-0. We could make zLOG available as egg or as downloadable product.
How would a user who got a zLOG import error know they needed to download something unless we leave a stub module and the deprecation warning in forever? Leaving it in and undeprecating it would allow lots of old products to work without any changes or users needing to download anything. This would be a win, IMO. I'm not sure of the goal of deprecating it in the first place. - C
--On 1. Februar 2007 12:31:12 -0500 Chris McDonough <chrism@plope.com> wrote:
On Feb 1, 2007, at 11:59 AM, Andreas Jung wrote:
--On 1. Februar 2007 11:01:56 -0500 Chris McDonough <chrism@plope.com> wrote:
How many people would get indignant if I checked in a fix that undeprecated zLOG? Removing the API seems silly, since its just a wrapper around the logging module now anyway.
-0. We could make zLOG available as egg or as downloadable product.
How would a user who got a zLOG import error know they needed to download something unless we leave a stub module and the deprecation warning in forever? Leaving it in and undeprecating it would allow lots of old products to work without any changes or users needing to download anything. This would be a win, IMO. I'm not sure of the goal of deprecating it in the first place.
0, for keeping zLOG for the time being... -1, for undeprecating it. Using Python's logging module should remain the only recommended solution. I don't want to see any new code using zLOG. Andreas
On Feb 1, 2007, at 1:06 PM, Andreas Jung wrote:
How would a user who got a zLOG import error know they needed to download something unless we leave a stub module and the deprecation warning in forever? Leaving it in and undeprecating it would allow lots of old products to work without any changes or users needing to download anything. This would be a win, IMO. I'm not sure of the goal of deprecating it in the first place.
0, for keeping zLOG for the time being... -1, for undeprecating it. Using Python's logging module should remain the only recommended solution. I don't want to see any new code using zLOG.
There's a good deal of code using it that we just don't see because it's "internal-only". When the API disappears, making people revisit that code is particularly pointless; it's makework. OTOH, if the API is not going to disappear, we should just undeprecate it. But anyway, all I can do is register my concern, you're gonna do whatever you do. ;-) - C
I'm OK with keeping it deprecated forever.
Chris McDonough wrote at 2007-2-1 13:32 -0500:
0, for keeping zLOG for the time being... -1, for undeprecating it. Using Python's logging module should remain the only recommended solution. I don't want to see any new code using zLOG.
There's a good deal of code using it that we just don't see because it's "internal-only". When the API disappears, making people revisit that code is particularly pointless; it's makework. OTOH, if the API is not going to disappear, we should just undeprecate it.
But anyway, all I can do is register my concern, you're gonna do whatever you do. ;-)
I am on your side, Chris. But, I fear, we will not be heard... I fight pointless deprecation warnings with global deprecation warning deactivation -- probably not what deprecation advocates hope for. -- Dieter
--On 2. Februar 2007 22:53:50 +0100 Dieter Maurer <dieter@handshake.de> wrote:
There's a good deal of code using it that we just don't see because it's "internal-only". When the API disappears, making people revisit that code is particularly pointless; it's makework. OTOH, if the API is not going to disappear, we should just undeprecate it.
But anyway, all I can do is register my concern, you're gonna do whatever you do. ;-)
I am on your side, Chris.
But, I fear, we will not be heard...
I fight pointless deprecation warnings with global deprecation warning deactivation -- probably not what deprecation advocates hope for.
With the argumentation that some old code might break with deprecated APIs you can fight almost against any kind of deprecation. We could possibly discuss and find some rules (specific for the Zope 2 needs) at Python if some of you guys show up in Dallas later this month. Andreas
On Feb 3, 2007, at 2:54 AM, Andreas Jung wrote:
With the argumentation that some old code might break with deprecated APIs you can fight almost against any kind of deprecation.
I think deprecations are good when they serve a good purpose, but IMO this specific deprecation has no benefit other than to break old code. The maintenance burden of zLOG is very small (it's only ~ 8K of code).
We could possibly discuss and find some rules (specific for the Zope 2 needs) at Python if some of you guys show up in Dallas later this month.
I won't be there, unfortunately.. they rejected my talk proposal ;-) - C
--On 2. Februar 2007 22:53:50 +0100 Dieter Maurer <dieter@handshake.de> wrote:
But anyway, all I can do is register my concern, you're gonna do whatever you do. ;-)
I am on your side, Chris.
But, I fear, we will not be heard...
One last remark. You all are highly recognized members of the community and you all have access to the repository. So if there is consensus about a particular topic you all have the freedom to change the codebase. Obviously the consensus seems to change from time to time. For zLOG case: a majority wants zLOG...so put it back (as I wrote already yesterday) and let's stop the discussion at this point :-) Andreas
Andreas Jung wrote:
0, for keeping zLOG for the time being... -1, for undeprecating it. Using Python's logging module should remain the only recommended solution. I don't want to see any new code using zLOG.
Totally agreed... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote:
Andreas Jung wrote:
0, for keeping zLOG for the time being... -1, for undeprecating it. Using Python's logging module should remain the only recommended solution. I don't want to see any new code using zLOG.
+1 for undeprecating it -- the noise it generates is usesless, and the value which its (attempted) removal has sucked out of our development process is far greater than any "hygeine" it was intended to create. At this point, the module is a thin compatibility wrapper for the logger, and no more. If *we* introduced lots of bugs into Zope trying to rip out zLOG from the core, why should we induce that same hell on people maintaining third-party products? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFwzvc+gerLs4ltQ4RAsUaAKCW0eC4+8Tde1kQhztWpzZZD65nsACfUG6D bfanqN4oZMd1EuiXGQVT8uE= =pJAc -----END PGP SIGNATURE-----
Tres Seaver wrote:
Chris Withers wrote:
Andreas Jung wrote:
0, for keeping zLOG for the time being... -1, for undeprecating it. Using Python's logging module should remain the only recommended solution. I don't want to see any new code using zLOG.
+1 for undeprecating it -- the noise it generates is usesless, and the value which its (attempted) removal has sucked out of our development process is far greater than any "hygeine" it was intended to create. At this point, the module is a thin compatibility wrapper for the logger, and no more.
If *we* introduced lots of bugs into Zope trying to rip out zLOG from the core, why should we induce that same hell on people maintaining third-party products?
That is a good point. I should note that the deprecation of zLOG happened a) without a proper proposal that *exactly* outlined how certain zLOG calls should be spelled. Such proposals serve as reference for everyone who has to update their code. b) without moving the whole Zope 2 codebase to the new API. That in turn ended up in a desaster because the different places zLOG was still used were fixed up one by one by different people who made mistakes (mostly because of point a)). I think those points account for some of the problems we've had; there have certainly been wilder refactorings that people could deal better with because they were better documented. Nevertheless, the proposed benefits (less code to maintain, etc.) don't seem to balance the effort we've needed even just for Zope core at this point. As said, I wouldn't mind if zLOG was added back and even undeprecated, just as much as I wouldn't mind keeping the current situation. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
--On 2. Februar 2007 15:09:53 +0100 Philipp von Weitershausen <philipp@weitershausen.de> wrote:
Tres Seaver wrote:
Chris Withers wrote:
Andreas Jung wrote:
0, for keeping zLOG for the time being... -1, for undeprecating it. Using Python's logging module should remain the only recommended solution. I don't want to see any new code using zLOG.
+1 for undeprecating it -- the noise it generates is usesless, and the value which its (attempted) removal has sucked out of our development process is far greater than any "hygeine" it was intended to create. At this point, the module is a thin compatibility wrapper for the logger, and no more.
If *we* introduced lots of bugs into Zope trying to rip out zLOG from the core, why should we induce that same hell on people maintaining third-party products?
That is a good point. I should note that the deprecation of zLOG happened
a) without a proper proposal that *exactly* outlined how certain zLOG calls should be spelled. Such proposals serve as reference for everyone who has to update their code.
b) without moving the whole Zope 2 codebase to the new API. That in turn ended up in a desaster because the different places zLOG was still used were fixed up one by one by different people who made mistakes (mostly because of point a)).
I think those points account for some of the problems we've had; there have certainly been wilder refactorings that people could deal better with because they were better documented.
Nevertheless, the proposed benefits (less code to maintain, etc.) don't seem to balance the effort we've needed even just for Zope core at this point. As said, I wouldn't mind if zLOG was added back and even undeprecated, just as much as I wouldn't mind keeping the current situation.
If anyone is interested in putting zLOG back into the core, put it back. However I am still opposed removing the deprecation. It should remain deprecated without the threat to remove it in Zope 2.11. That's a clear message to avoid using zLOG for new code. The recommended solution for logging in Zope 2 country is and will be the 'logging' module of Python. Andreas
-- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting
participants (7)
-
Andreas Jung -
Chris McDonough -
Chris Withers -
Dieter Maurer -
Lennart Regebro -
Philipp von Weitershausen -
Tres Seaver