I'll also reiterate Cory's compliments that the post was great! For me there are two questions the post raises. One is how do we keep people from tying themselves to any one event loop? I view sans-io as the start of this, but it does require getting people to know about it, implement protocols that way, and then continuing to abstract themselves in such a way so as to not tie themselves down. But then we start to go up a level to things that work at the HTTP level and then it starts to get complicated and I don't know if we have a solution yet for e.g. an async GitHub SDK library that is event loop-agnostic when it comes to HTTP requests/responses.
Two, how long do we put off "the future" for some async/await-native event loop to emerge and hit production quality? I totally understand David wanting to keep curio experimental, but at some point something will either need to reach stable for people to seriously use or "the future" will simply stay in the future and people will just tie themselves to the asyncio abstractions, making it that much harder for people to try something else. As I think all of us realize, async/await is giving us a rare opportunity to set the future tone for networking code in Python, but at some point a tipping point will be reached and whatever common practice is in place at that point might calcify, so figuring out how we want things to be in the general landscape would be good. I would also like to thank everyone involved with defining async/await. I think the fact that async/await is an API and not something tightly bound to any specific event loop like in pretty much every other async-supporting language has been very beneficial to us and something to celebrate. The sheer fact that people who don't like asyncio, Twisted, Tornado, or curio have other options is fantastic. On Sun, 6 Nov 2016 at 02:55 Cory Benfield <c...@lukasa.co.uk> wrote: > > > On 6 Nov 2016, at 00:09, Nathaniel Smith <n...@pobox.com> wrote: > > > > I just posted a long blog/essay that's probably of interest to folks > here: > > > > > https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-post-asyncawait-world/ > > > > The short version: I think curio something important to teach us; I > > tried to figure out what that is and how we can learn from it. > > This is a great post Nathaniel, and I think there’s a lot of value to > extract from this for everyone. > > In the short term, I’m going to address Twisted’s issue because it seems > like the most glaring “this is a stupid bug” problem, and a quick glance at > the relevant interfaces suggests it’s easily resolved. It also undermines > my own personal mission to make Twisted a great HTTP/2 server. ;) > > Cory > _______________________________________________ > Async-sig mailing list > Async-sig@python.org > https://mail.python.org/mailman/listinfo/async-sig > Code of Conduct: https://www.python.org/psf/codeofconduct/
_______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
