At 05:00 PM 10/4/2007 +0200, Manlio Perillo wrote: >Your are making a critical decision here. >You are lowering the level of WSGI to match the level of average WSGI >middlewares programmers.
No, we're just getting rid of legacy cruft that's hard to support correctly. There's a big difference. >This can have disastrous conseguences if Python will gain a large user >base in the future (and, of course, with a large user base, the majority >of the users will have a low profile). This seems to be arguing the opposite: making WSGI simpler is a *good* thing if there will be a larger user base. > >> It's very unfortunate that the WSGI implementation in Twisted just uses > >> threads instead of doing some experimentation. > > > > You're making the assumption that no experimentation was done. Check > > the Web-SIG archives from three years ago and see the discussions about > > async APIs. > >No. >I have read a lot of archived messages, and all I have seen are >*discussions* about asynchronous extensions, but no working implementations. Because nobody came up with anything particularly useful. While it's possible to have generic extensions for pausing and resuming iteration, those aren't useful enough to write a fully asynchronous application. You still have to block and/or poll in order to do anything else. Meanwhile, since applications *can* block, they have to be in a separate thread or process from an async server anyway. So all that asynchrony does is free up the thread or process to handle something else... which is wasted if the app is not in an async server. So, barring a radical alteration to the WSGI programming model, asynchronous programming is a bit of a dead-end. To do async right, you really need a CPS (continuation-passing style) API, *and* you also need async APIs for whatever the app is going to *do*. In other words, the absence of standard Python APIs for asynchronous I/O (be it socket, database, or otherwise) make it moot to add an async API to WSGI, since in practice the application will be locked-in to whatever async I/O API it uses. _______________________________________________ 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
