[Zope] Re: filter messages at startup

[Chris McDonough]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

>
> --On 14. Juni 2006 10:25:57 +0200 thomas desvenain  
> <thomas.desvenain at gmail.com> wrote:
>
>> 2006/6/13, Chris McDonough <chrism at plope.com>:
>>> 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
>> time
>> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFEj9mE8sgUgRRnf6URAtE6AJ9U4qiIL+azduJpVb7vizGmfBn5rQCaAoao
lH8rgzCU5/e1IpwTBPcwZTQ=
=uQ3M
-----END PGP SIGNATURE-----