Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
API: highlevel strategy discussion #42
I feel like trio-asyncio's core functionality is been pretty solid for a while, but we're still flailing a bit trying to find the most usable way to expose it to users. I guess right now it has 3 different APIs, we're discussing a 4th, and it's not clear whether any of them is actually what we want? And I'm frustrated that I don't feel like I understand what the pitfalls are or what features users actually need. And my main coping strategy for that kind of frustration is to open an issue and write a bunch of text to organize my (our?) thoughts, so here we go. Hopefully laying out all the information in one place will give us a clearer picture of what the trade-offs actually are, and help us find the best way forward. (4 overlapping APIs and constant churn cannot be the solution!)
What I think I know
Strategies we've tried:
Some tentative conclusions?
So....... maybe I've argued myself into thinking that
They even make a reasonable substitute for
@aio2trio async def this_is_called_by_homeassistant(): # And I write Trio code inside it
async def this_is_called_by_homeassistant(): async with trio_mode: # And I write Trio code inside it
One extra level of indentation, but the same number of lines, and no need for anything really annoying like writing a trampoline function.
What am I missing?
Probably a bunch of stuff, but hopefully laying out my thinking will make it obvious to someone what terrible mistakes I'm making? Please help me be smarter :-)
A few more questions that didn't fit into the above:
Thanks for the write up!
I don't know what you're missing and never used trio-asyncio, but if your premises are correct, I do agree with your conclusions:
In my opinion, the API should be simply the
The basic primitives should be exposed, but like, not the way to do anything unless you need them. This would be, in my opinion, the simplest and easiest way to do everything.
@njsmith You're right in that
referenced this issue
Sep 24, 2018
added a commit
Sep 26, 2018
It looks like the three primitives we need to implement coroutine runner switching are:
On the Trio side, we control everything, so these are all pretty straightforward to implement. On the asyncio side I think we can implement these as:
A first attempt would be to (a)
Alternatively we could try mutating
We should also check
So we might want to make sure
These options are all pretty terrible; if we go ahead with this we should talk to the asyncio folks about making sure that in 3.8 there's a nicer API for this, or at least that our terrible hacks don't break, to avoid a repeat of #23. BUT, it does look like there aren't any show-stoppers currently, so we should probably prototype this out and decide whether we're actually going to commit to it before we talk to the asyncio folks about it.