Re: [Web-SIG] about wsgiref.headers.Headers
Phillip J. Eby ha scritto: > At 08:34 PM 1/17/2008 +0100, Manlio Perillo wrote: >> Hi. >> >> What is the rationale for Headers._headers being private? > > The code was mostly a copy-and-paste job from email.Message, which did > the same. At one point, it might actually have been a subclass of > email.Message, and so it was required. > Having the `_headers` private is ok for the email.Message, but I think it is wrong for wsgiref, since the Headers class is just a wrapper for the headers list. Manlio Perillo ___ 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
Re: [Web-SIG] about wsgiref.headers.Headers
At 08:34 PM 1/17/2008 +0100, Manlio Perillo wrote: >Hi. > >What is the rationale for Headers._headers being private? The code was mostly a copy-and-paste job from email.Message, which did the same. At one point, it might actually have been a subclass of email.Message, and so it was required. ___ 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
[Web-SIG] about wsgiref.headers.Headers
Hi. What is the rationale for Headers._headers being private? Thanks Manlio Perillo ___ 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
Re: [Web-SIG] loggers and wsgi
Chris Withers ha scritto: > 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. > This is not a problem. The job can be done by a middleware. My idea is to add a message like interface to wsgi.input, in addition to the stream interface. > 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. > Again, not a real problem, IMHO. This is the only solution for better support several environments. > 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...) > No, I think this is wrong. This can be done, of course, by a middleware. > 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 ;-) > This is only a work around. I think that, where possible, WSGI must allow better integration with the "server environment". By the way, there is still the problem with a stream/message object not bound to a single request; this is required by applications that needs to log, as an example, a database connection pool. > cheers, > > Chris > Manlio Perillo ___ 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
Re: [Web-SIG] loggers and wsgi
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
