[Zope-dev] Deprecation process issues

2006-01-16 Thread Tres Seaver
-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  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://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-

___
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 )


Re: [Zope-dev] Deprecation process issues

2006-01-16 Thread Jim Fulton

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:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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 )


Re: [Zope-dev] Deprecation process issues

2006-01-16 Thread Andreas Jung



--On 16. Januar 2006 13:08:31 -0500 Jim Fulton [EMAIL PROTECTED] 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



pgpO4ad33XNks.pgp
Description: PGP signature
___
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 )