Github user aboudreault commented on the issue:
https://github.com/apache/tinkerpop/pull/478
@davebshow @aholmberg (PYTHON) I must agree that my initial thought is that
we should try to avoid the coupling with tornado. However, since tornado is
already used internally, it might get better performance since it is optimzed
and non thread-safe for the loop.
If I understand correctly, a custom RemoteConnection will need to return
its own future type. Isn't a bit confusing for the user that he will get
different future types? I was seeing the RemoteConnection as the transport
layer and that it was transparently pluggable. With this change, we see that it
has an impact on the API of the query response. IMO, for that reason, we might
want to consider a specialized handling of the future returned by the traversal
query.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
