-
Notifications
You must be signed in to change notification settings - Fork 76
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
Remove asyncio metaprogramming #77
Comments
ghost
pushed a commit
that referenced
this issue
Nov 8, 2020
First step to remove our asyncio metaprogramming... #77 Our Query class now provides a run method for synchronous users, and run_async for asyncio. This also adds a stop method that can cancel our download.
Unfortunately I moved on from Tor before finishing this. My plan was to revert the Controller back to being synchronous, but with an async msg method and asynchronous socket objects (that is to say, async low level components with a synchronous wrapper). I spent a month on this but it's not yet done... https://gitweb.torproject.org/user/atagar/stem.git/log/?h=bug77 |
Closed
This was referenced Nov 12, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To transparently support both synchronous and asynchronous usage we use metaprogrmming. Basically, our mixin matches method calls to the context type we run within.
When a synchronous controller is used within an event handler we mistakenly treat it as being asynchronous. For example...
The trouble here is that our listener invokes within our controller, which is an asynchronous context. Needless to say, this is confusing as hell.
I'm going to revisit and likely remove our asyncio metaprogramming. It's complicated, breaks type checks, and liable to keep causing problems. Pitching this on the python list and stack overflow I get the sense that this isn't a promising approach long term.
The text was updated successfully, but these errors were encountered: