Note that you don’t need to repeatedly enforce the same argument. Participants are free to make their points, but these points are not decisive. They help explore edge cases, and sometimes the points are made just for the sake of completeness.
I’m not enforcing the same argument every single time?
It’s been different each time? I showed you why an exception workaround would be inconvenient to implementers of a library, I then made an argument about how async iterators support this but not async generators which is a seperate kind of inconsistency.
I gave you a workaround in my first post because, in the best-case scenario, you could use the proposed feature after a year, in Python 3.14. Are you willing to wait a year?
Of course I’m willing to wait a year for this feature, I didn’t come here to solve my problem immediately, I came here because I saw a deficiency in the language and thought I could help by being a champion for a new change.
The mere fact that there has been no interest in implementing all synchronous generator features into the asynchronous ones would indicate that these features are not highly desired or have been replaced by asyncio asynchronous frameworks.
This is just not true. I suspect most people run into this issue and then have to find a work around.
- If you read @bluetech’s post (a maintainer of pytest) they also run into this problem.
- Here is another post Return with value allowed in generators but not async generators? - #3 by MadcowD
- Here is another `yield from` in async functions - #12 by yoavdw
I understand that you might not like the ideas here, but I would appreciate it if you would please kindly respond to the points in my counter arguments instead of trying to shut off conversation here based on “interest” or “my writing style”. I want to discuss the actual meat and bones here and I think you have some really good ideas so I’d love to hear what your genuine thoughts are to my responses.