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
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...
from stem.control import Controller, EventType
with Controller.from_port() as controller:
controller.authenticate()
print(controller.get_version()) # this prints our version
def listener_func(event):
print(controller.get_version()) # this prints "<coroutine object Controller.get_version at 0x7f87d29da640>"
controller.add_event_listener(listener_func, EventType.BW)
input()
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:
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...
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: