At 07:38 PM 10/5/2007 +0200, Manlio Perillo wrote: >Phillip J. Eby ha scritto: > > I still don't see how this is *useful*. What will the application *do* > > with this information? > >As an example (not tested) SQLAlchemy can implements a >RequestSingletonPool, that is the equivalend of ThreadSingetonPool. > >In this case the pool will checkout a connection using the >environ['wsgi.request_id'] identifier (unique for each request), instead >of thread.get_ident.
I still don't see the point of this. Why can't the application just keep a reference to the connection object it's using? That doesn't require any new code and already works now in every existing WSGI server. Why write code that is more complex to do something that you don't even need? Not only that, but the ONLY reasons for the application to yield are if it's sending something too big to fit in memory, or it's doing server push (or otherwise wants to stream the content). Such applications are extremely rare to begin with, or should be. If you are seeing applications that yield multiple strings and *aren't* one of these use cases, it indicates that the application author doesn't understand the WSGI spec, and doesn't realize they're slowing down their application by doing it. Yields are for streaming, and most web applications shouldn't be streaming. That means that 99.9% of all WSGI applications should never produce more than one output string -- which means that the "interleaving" question never even comes up. The applications that produce multiple output strings have to deal with the complexity of the situation anyway. _______________________________________________ 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