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

+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.

-- -- Professional Zope documentation and training
Next Zope 3 training at Camp5:
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to