Trio support
decentral1se opened this issue · 7 comments
Hey, thanks for this awesome looking library. I'm investigate the feasibility of using it on one of my projects and I see that pyee supports asyncio and twisted for async capabilities. I am wondering if there is any motivation to also support the trio library:
I'm relying on the trio async streams implementation and I'd also like to be able to plug on this event emitter class onto my stream. What do you think?
I'm down to support the trio library. I thought trio's Futures were naively compatible with asyncio's - is that not the case?
If you want to sketch out what trio support would look like (aside from what exists now), I can help iterate on the ideas and give adding support for it a shot. Otherwise, if you want to take a crack at it and just PR what you want here you should be able to do something similar to the asyncio EE which subclasses the BaseEventEmitter and adds special handling around the result of a handler function.
I did some quick research, it looks like the necessary abstraction is called a nursery. Adding support for this looks relatively straightforward.
more research, unlikely to actually bang this out tonight but I can at least get my notes here
so the nursery is def the correct abstraction, though it should be noted that nurseries are async contextmanagers - so I could potentially make TrioEventEmitters also async contextmanagers. this would be loosely similar to how ExecutorEventEmitters optionally use sync contextmanagers. cool beans!
and here's how I can sense the event for the tests:
Between these, this sounds like a few hours of work. I can probably hack this up sometime over the weekend!
Thanks a lot! I'm trying to catch up on the discussion in the trio gitter and that was pretty helpful to understand why this is also perhaps not the correct approach to what I want to do. Since the asyncio streams people and trio streams people are collaborating closely, I am inclined to listen to their thoughts about structure ;) I am wondering perhaps now if I shouldn't just close this off and save you the work! Perhaps this is just a docs issue!?
it's true that an EventEmitter might not be the best solution to your problem, though I can't really tell you that either way. I would need a lot more information about your use case, and probably greater familiarity with trio, to say anything intelligent here.
all that said, please keep this issue open. I actually thought trio's interop with asyncio was a lot tighter (meaning this exposed a use case I wasn't aware of) and I'm totally down to implement even if it's "non-idiomatic". like I said in the gitter, I don't really care about dogma and I don't have a horse in this race.
I'm not into the dogma either but there is some stream gathering around this idea of structured concurrency now and I want to find the surest path for my work that won't have me re-writing all the things.
OK, let's keep this open 👍