> > > > I realise this may sound bikesheddy, but it would be really good to > not call it ASGI. From your docs " > Despite the name of the proposal, ASGI does not specify or design to > any specific in-process async solution, such as asyncio, twisted, or > gevent. Instead, the receive_many function can be switched between > nonblocking or synchronous. This approach allows applications to > choose what’s best for their current runtime environment; further > improvements may provide extensions where cooperative versions of > receive_many are provided." > > I'm worried that folk will assume a parallel between ASGI and asyncio, > but there appears to be none... which is only a problem due to the > room for confusion.
Better names are welcome, but I quite like ASGI's similarity to WSGI, and the fact it's pronounceable as a single word. The "Asynchronous" part covers the way the whole system operates; async is already an overloaded term, and while there might be initial confusion, I think "async" also has strong associations with the sort of problems ASGI solves (like websockets), which I think is useful. > For consistency, why not a dict unicode -> List[bytes] I personally think this is worse than a list of tuples (which you can at least feed straight into dict()) - the only header that comes through as multiple, ever, is Set-Cookie, after all. Andrew
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com