On 05/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 09:03 AM 10/5/2007 +1000, Graham Dumpleton wrote: > >Too early for me to be thinking straight and work it out for myself, > >but does this all help in making it simpler or more obvious what the > >cleanup requirements are for a generator. Ie., correct use of > >try/except/finally around yield and purpose of close() function. I've > >seen a number of people not get this correct in stuff and tried to > >correct them. Hopefully I have captured what should be done correctly > >in my document: > > > > http://code.google.com/p/modwsgi/wiki/RegisteringCleanupCode > > That's fine, and none of it would change for WSGI 2.0, except minor > details of what wraps what. > > Note, by the way, that as of Python 2.5, a generator can have > try/finally and its close() method will be called when it finishes or > is garbage collected. So an app_iter implemented as a generator > under 2.5 can just use with: or try/finally to handle cleanup -- and > that applies equally to WSGI 1 and 2.
Yep, know about the Python 2.5 difference. Didn't want to talk about it though so that people would just use the way that would also work with older versions of Python. BTW, have been thinking about doing it for a long time, but truly wasn't sure that WSGI 2.0 would ever actually happen, but now that discussion is happening again I will add to Apache mod_wsgi a directive WSGIProtocolVersion which would allow experimental 2.0 implementation to be switched on for specific applications. Having this and perhaps other experimental implementations may help to flush out any issues when we start discussing details, especially as Apache imposes its own quirks that others tend not to have to deal with. Adding this support in should be quite trivial. Once that is done and the discussion about asynchronous implementations dies down, might initiate discussions about some other issues such as wsgi.input, end of input indicators and content length issues for streamed request content and mutating input filters etc. Graham _______________________________________________ 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