-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've noticed a couple of problems with recent deprecation decisions (for OFS.content_types and zLOG). The major one is that the deprecation warning waw added without removing the code in the core which depends on the deprecated feature. The most obvious sign of this is that the tests no longer "run clean", but are cluttered up with warning output. Another issue is that at least one of those choices (the zLOG one) seemed to land without accounting for the legitimate use cases which the new "blessed" method doesn't address (e.g, logging levels not offered by the standard 'logging' module). I'm about to check in changes which clean out the use of OFS.content_types, but am less willing to clean up the zLOG uses until the other use cases are addressed. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDy9kb+gerLs4ltQ4RAiPBAJ0RD0HF3r0GhOm9JqTtsF/o1M/z3ACeNJTs 37iQ0WGsxgCYBOQ81xw9XnE= =+CgN -----END PGP SIGNATURE-----
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've noticed a couple of problems with recent deprecation decisions (for OFS.content_types and zLOG). The major one is that the deprecation warning waw added without removing the code in the core which depends on the deprecated feature. The most obvious sign of this is that the tests no longer "run clean", but are cluttered up with warning output.
Another issue is that at least one of those choices (the zLOG one) seemed to land without accounting for the legitimate use cases which the new "blessed" method doesn't address (e.g, logging levels not offered by the standard 'logging' module).
I'm about to check in changes which clean out the use of OFS.content_types, but am less willing to clean up the zLOG uses until the other use cases are addressed.
I haven't been following these issues, counting on y'all to figure it out. :) I'll just note that: - I agree with your point about deprecation warnings. IOW we should not check in new deprecation warnings on the trunk that cause warnings to be output when running the standard tests. We should correct any code that needs to be updated first. (Personally, I add the deprecation warning, making sure that I get the expected warnings, and then I make the warnings go away.) - I think that dropping functionality should be considered carefully. I'm inclined to accept your judgement that the use cases need to be addressed. Of course, we do want to move away from zLOG, as we want to leverage the standard logging framework. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
--On 16. Januar 2006 13:08:31 -0500 Jim Fulton <jim@zope.com> wrote:
I'll just note that:
- I agree with your point about deprecation warnings. IOW we should not check in new deprecation warnings on the trunk that cause warnings to be output when running the standard tests. We should correct any code that needs to be updated first. (Personally, I add the deprecation warning, making sure that I get the expected warnings, and then I make the warnings go away.)
But you can only correct code when you have a reasonable replacement. In case we should use my current ZPT replacement based on the Z3 implementation we would deprecate lib/python/TALES and have deprecation warnings for two major releases. But we can't replace lib/python/TALES with the Z3 tal|tales packages since we can expect incompatibilities which are not acceptable for backward compatibility issues. One could write fascades for such modules (Philipp already wrote one for STX) but I doubt that they will be 100% compatible. I would prefer to keep such modules in place and to just remove them after the deprecation period.
Of course, we do want to move away from zLOG, as we want to leverage the standard logging framework.
Has there ever been the need/demand for additional log levels in Z3? -aj
Andreas Jung wrote:
--On 16. Januar 2006 13:08:31 -0500 Jim Fulton <jim@zope.com> wrote:
I'll just note that:
- I agree with your point about deprecation warnings. IOW we should not check in new deprecation warnings on the trunk that cause warnings to be output when running the standard tests. We should correct any code that needs to be updated first. (Personally, I add the deprecation warning, making sure that I get the expected warnings, and then I make the warnings go away.)
But you can only correct code when you have a reasonable replacement. In case we should use my current ZPT replacement based on the Z3 implementation we would deprecate lib/python/TALES and have deprecation warnings for two major releases. But we can't replace lib/python/TALES with the Z3 tal|tales packages since we can expect incompatibilities which are not acceptable for backward compatibility issues. One could write fascades for such modules (Philipp already wrote one for STX) but I doubt that they will be 100% compatible. I would prefer to keep such modules in place and to just remove them after the deprecation period.
There are two separate issues here: 1. ZPT backward compatibility. Are we introdcuting ZPT backward incompatibilities? (Aside from module paths)? If so, then I think we need to have a proposal. (Maybe you already made one and I wasn't paying attention. I don't see one at: http://www.zope.org/Wikis/DevSite/Proposals/FrontPage. 2. If we decide to change something, even if it's backward incompatible, we need to change Zope itself to do things the new way before we expect other people to and before we introduce the deprecation warning. If there isn't a valid new way of doing something, then we can't deprecate the old way. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
--On 16. Januar 2006 13:36:32 -0500 Jim Fulton <jim@zope.com> wrote:
There are two separate issues here:
1. ZPT backward compatibility.
Are we introdcuting ZPT backward incompatibilities? (Aside from module paths)?
My original implementation would introduce incompatibilities definitely. However I've just checked in a relaxed implementation that defaults to the current behaviour. Enforcing unicode is now an optinal feature which might be used for application that are interested to use unicode for ZPTs starting Zope 2.10.
If so, then I think we need to have a proposal. (Maybe you already made one and I wasn't paying attention. I don't see one at: http://www.zope.org/Wikis/DevSite/Proposals/FrontPage.
Well, I brought this issue up on zope-dev to discuss this issue directly. but with almost zero feedback :-) Also another related posting to zope-zpt got _zero_ anwers. Also other changes happened are part of a (pending) proposal written by Philipp.
2. If we decide to change something, even if it's backward incompatible, we need to change Zope itself to do things the new way before we expect other people to and before we introduce the deprecation warning.
Nothing else happened so far (except the issue with OFS.content_types in Zope 2.9. I just forgot to change the code for the 2.9 final release. There was something to hinder me from doing that for 2.9b2). -aj
Andreas Jung wrote at 2006-1-16 19:55 +0100:
... Well, I brought this issue up on zope-dev to discuss this issue directly. but with almost zero feedback :-) Also another related posting to zope-zpt got _zero_ anwers.
I have seen some answers -- though not too many... Note also that "zpt@zope.org" is a very low activity list. For it, a few answers is already a lot... -- Dieter
Dieter Maurer schrieb:
Andreas Jung wrote at 2006-1-16 19:55 +0100: ... I have seen some answers -- though not too many...
Note also that "zpt@zope.org" is a very low activity list. For it, a few answers is already a lot...
Add to it the fact the zpt@zope.org was due to be retired anyway ;)
On 1/17/06, Tino Wildenhain <tino@wildenhain.de> wrote:
Add to it the fact the zpt@zope.org was due to be retired anyway ;)
Though retirement for the list was discussed, it was decided not to retire it since it was still the best place for implementors to discuss matters. The implementations in Zope 2 and Zope 3 are not the only implementations, and the other implementors are justifiably not interested in joining Zope-specific lists. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "There is no wealth but life." --John Ruskin
Jim Fulton wrote at 2006-1-16 13:36 -0500:
... 2. If we decide to change something, even if it's backward incompatible, we need to change Zope itself to do things the new way before we expect other people to and before we introduce the deprecation warning. If there isn't a valid new way of doing something, then we can't deprecate the old way.
I am very happy that you write this. -- Dieter
Tres Seaver wrote:
I've noticed a couple of problems with recent deprecation decisions (for OFS.content_types and zLOG). The major one is that the deprecation warning waw added without removing the code in the core which depends on the deprecated feature. The most obvious sign of this is that the tests no longer "run clean", but are cluttered up with warning output.
Yes this is a major pain. Such that in my sandboxes the first thing I do is comment out the warning in zLOG. Florent
Another issue is that at least one of those choices (the zLOG one) seemed to land without accounting for the legitimate use cases which the new "blessed" method doesn't address (e.g, logging levels not offered by the standard 'logging' module).
I'm about to check in changes which clean out the use of OFS.content_types, but am less willing to clean up the zLOG uses until the other use cases are addressed.
-- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
participants (7)
-
Andreas Jung -
Dieter Maurer -
Florent Guillaume -
Fred Drake -
Jim Fulton -
Tino Wildenhain -
Tres Seaver