| > To be honest, I think she might be biased here given that she maintains a competing package. I hope that you take time to reconsider this view. We're not talking about competition in the same sense as in a capitalist system, between two companies. Prior to asyncio, Twisted maintained the only viable flow control for serious asynchrony in python. Put another way, python had no standard flow control for serious asynchronous abstractions in the standard language (and standard library) before asyncio (and `await/async def`, etc) landed. Nobody is saying that the syntactical changes to python belong in a separate package on PyPI (cue Gary Bernhardt's Pretzel Colon). These things are fine. But `asyncio.Future`? Yeah, I see a very reasonable argument for that stuff (ie, the asyncio namespace) being in a separate package. But OK - looking again at the "competing package" narrative: now that these things have landed, Twisted has done an amazing job of using them alongside all the other tooling that Twisted also provides, most notably its test infrastructure. Amber doesn't stand to personally benefit from asyncio failing. To the contrary, having the flow control taken care of so that Twisted doesn't have to be its sole brainparent gives her much less free work to feel obligated to do. |
Could you provide a reference/explanation for this? Thanks in advance!