Hash: SHA1

On Jun 14, 2006, at 4:36 AM, Andreas Jung wrote:

--On 14. Juni 2006 10:25:57 +0200 thomas desvenain <[EMAIL PROTECTED]> wrote:

2006/6/13, Chris McDonough <[EMAIL PROTECTED]>:
I suppose a log call is fine.

I *really* like these messages, because they catch a lot of my own
boneheaded security declaration errors.  But for ones that aren't
actually "real" problems (like the ones shown by the OP), it would be
nice to be able to filter them away at startup, especially when
starting in the foreground or running "zopectl debug" or "zopectl
test".  Making these into actual warnings.warn calls would let us do
that with a warnfilter, but any other solution would be fine as well.

In my way those messages can be usefull for everybody... but not at every
it would be nice to get a tool (using regexp) to adapt them to our
present needs (installing a product, developping a product on a test
instance for example)

From the practical point of view: just close your eyes. When you run a
server in production you will see those messages only in the logs. If you are a developer you should be aware of the content of the messages and fix your own code or upgrade the related products.

It's just not possible to upgrade components of every configuration. Sometimes you just need to live with some specific configuration for a while. It's not really a bad thing to have a known-working configuration, even if it's a little old.

If we turned these log calls into warnings.warn calls, they could be filtered out by warnfilter configuration, no big deal, we could solve the "cant upgrade right now b ut don't want to see warnings" problem, nobody would need to write any code to filter out specific log messages or do anything else. I think that's practical too. This is what the warnings module is for.

In particular, these specific errors indicate a totally harmless condition and the errors' existence in the log isn't helpful to consumers who for whatever reason can't upgrade. Developers will continue to see warnings.warn messages because they always run things in the foreground and warnings.warn messages are sent to stderr, so it's not like they'd miss any deprecation messages if we changed it.

If developers were really interested in being anal about things, a warnfilter configuration can turn warning messages into errors for their specific sandbox. If they really, really wanted the messages to be written to a logfile, they can override warnings.showwarning in their site configuration. I doubt anybody will care that much, though.

Given the above, if there's not total opposition to this, I'd volunteer to make these log calls into warnings during bugday tomorrow on the 2.8, 2.9, and 2.10 branches. It might be a good idea to turn all deprecation warnings in the core like this into warning messages, especially given that the core itself generates warnings now due to its own use of features that have been marked as deprecated.

- - C

Version: GnuPG v1.4.3 (Darwin)

Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to