You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
They will error out by not finding __aiter__. At first sight this is easy to add, and I was planning to just drop a PR and walk off, but there are a few design decisions here.
Should we just call next() on whatever thread in the thread pool as __anext__ is called? Or should we trap a thread for the lifetime of the iterator, detecting iterator abandonment using the weakref module? Should that be exposed as an option in the decorator?
The text was updated successfully, but these errors were encountered:
My main first concern is the blocking API calls will have to be made more complicated to handle this async iterator case. With that ground work I think it will be easier to consider this use case of converting conventional iterators to async ones. (Which is a super a cool idea by the way!)
Hm, I hadn't considered that. Part of the problem is that async iterators are rich objects that receive calls with arguments and whatnot. There's even more thought involved than I initially thought! :)
Scenarios like these are not currently supported:
They will error out by not finding
__aiter__
. At first sight this is easy to add, and I was planning to just drop a PR and walk off, but there are a few design decisions here.Should we just call
next()
on whatever thread in the thread pool as__anext__
is called? Or should we trap a thread for the lifetime of the iterator, detecting iterator abandonment using theweakref
module? Should that be exposed as an option in the decorator?The text was updated successfully, but these errors were encountered: