Manlio Perillo wrote: > > wsgi.errors maybe should have an optional method: > .msg(level, *args) > > where args is a list of strings > > or > .msg(*args, **kwargs) > > where the keys in kwargs are implementation defined.
I don't really see how this helps. If it's optional, then ever wsgi app will need a bunch of if/then/else to decide if this method can be called and what to do instead. Likewise, having implementation defined parameters means the application developer has to tie the app to a list of compatible servers and cater for each one. Surely a much better idea would be to give wsgi.errors a logger attribute which behaved like a standard python logger? (or, in fact, just make wsgi.error a python logger object...) The only problem here is that the level specified won't necessarilly match up to the server's idea of levels, but this is a mapping that can either be done intelligently in the server implementation or, worst case, by the person putting the components together in the server configuration files. >> Still, there's no problem with a wsgi application doing its own >> logging to its own log files, right? >> > There is an interoperability problem with external tools like logrotate, > since some WSGI implementation are unable to catch signals. That's why logrotate has copy-truncate ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com