Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trio support #61

Closed
decentral1se opened this issue Nov 14, 2019 · 7 comments
Closed

Trio support #61

decentral1se opened this issue Nov 14, 2019 · 7 comments

Comments

@decentral1se
Copy link

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:

https://trio.readthedocs.io/

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?

@jfhbrook
Copy link
Owner

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.

@jfhbrook
Copy link
Owner

I did some quick research, it looks like the necessary abstraction is called a nursery. Adding support for this looks relatively straightforward.

@jfhbrook
Copy link
Owner

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:

image

Between these, this sounds like a few hours of work. I can probably hack this up sometime over the weekend!

@decentral1se
Copy link
Author

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!?

@jfhbrook
Copy link
Owner

jfhbrook commented Nov 15, 2019

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.

@decentral1se
Copy link
Author

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 👍

@jfhbrook
Copy link
Owner

#62

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants