[Noah] > +1 on the iterator, although I might just like the idea and might be missing > something important. It seems like there are a lot of powerful things being > developed with generators in mind, and there are some nifty things you can > do with them like the contextlib example: > http://docs.python.org/library/contextlib.html#contextlib.closing
Indeed, like coroutines. http://www.python.org/dev/peps/pep-0342/ [Robert] >> The counter-argument was that >> servers could use non-blocking sockets to allow apps which read() to >> yield in the case of no immediate data rather than block indefinitely. Ah, but the problem with that is that one can't magically suspend methods like that and return control to the scheduler, without using coroutines or stackless. Who does the read() method return control to when there's no data available (i.e. no bytes on the socket). If wsgi.input is a simple file-like object, then it's methods must be coded to recognise, rather than blocking, when the data is not yet available to fulfill the applications expectation. How does it know how to return control to the scheduler, instead of the application? If the application expects to receive all of the data that it asked for with a, say read(1024) call, it has to be prepared to accept that it may get less than 1024 bytes, in an asynchronous situation. What does it return to the application in the case when < 1024 bytes is available? >> If a file-like object were retained, it would help to publish a >> chainable file example to help middleware re-stream files they read any >> part of. I don't think that re-streaming of input should be a part of the spec; it's an application layer thing. We don't expect to re-stream the output of an application: why re-stream the input? If some application needs to examine the entire byte sequence for whatever reasons, that's a special case that can be catered for with itertools, and dedicated middleware. >> Continuing deferred issues >> * Lifecycle methods (start/stop/etc event API driven by the container) I'd really like to get this one nailed: java people and .net people expect this stuff. Alan. _______________________________________________ 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
