-----BEGIN PGP SIGNED MESSAGE-----
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
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
In my way those messages can be usefull for everybody... but not
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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
-----END PGP SIGNATURE-----
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -