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

[For Discussion] Should generator pattern use asynchronous generators? #84

Open
3 tasks
cboulay opened this issue Jan 25, 2024 · 0 comments
Open
3 tasks

Comments

@cboulay
Copy link
Collaborator

cboulay commented Jan 25, 2024

Currently, the generator examples and gen_to_unit are not asynchronous. This is probably for the best as it's much more straightforward to implement and test the generator when we don't need to setup the async context. However, if there is a method/Unit that would truly benefit from asyncio (e.g., this list, something that needs to sleep, or if I expose async methods in pycbsdk) then the current generator examples and gen_to_unit are incompatible.

There are asynchronous generators in Python. As far as I can tell, the only difference is the method should be async def'd and you interact with it via asend or anext instead of send and next. Edit: Silly me, our Unit's subscriber and publisher methods are async generators.

How can we support asynchronous generators, while keeping synchronous generators as the default?

  • Example implementation with manual result = await gen.asend(msg) inside a Unit.
  • Either agen_to_unit or augment current gen_to_unit to recognize async def generators (inspect.iscoroutinefunction(generator)).
  • Either aconsumer or augment @consumer decorator to recognize async def.
@cboulay cboulay changed the title For Discussion: Should generator pattern use asynchronous generators? [For Discussion] Should generator pattern use asynchronous generators? May 11, 2024
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

1 participant