Github user davebshow commented on the issue: https://github.com/apache/tinkerpop/pull/478 I agree with the `RemoteConnection` implementation being pluggable. Therefore, the GLV should be able to use any remote connection as long as it complies with the API. But, since pre-Python3 doesn't have any standard implementation of a `Future`, in order to maintain this "plugablity", IMO the GLV should be able to handle whatever type of `Future` the `RemoteConnection` returns. This places the onus on the end user to understand what `RemoteConnection` implementation they are using and the type of Future returned in order to comply with the syntax required by underlying framework implementation. This does not mean that responses need have a different API, only that developers know how to either `yield` or `yield from` them, or use the `concurrent.futures.as_completed` method. The good thing is that the three possible future types (asyncio, tornado, and concurrent) have compatible APIs, and should be able to all be handled by the GLV in the same fashion. However, if I understand correctly (not sure that I do) it seems to me that doing specialized handling, would require us to commit to a certain syntax. Unfortunately, all of these problems really stem from the Python community's unwillingness to drop the legacy Python implementation, which the Python Software Foundation has been urging us to do for years. If I am missing something, or there is a solution that I can't see for some reason, please provide an example of a way that allows any pluggable `RemoteConnection` that can be based on any of the possible Python frameworks that maintain the syntax used for handling the resulting future by the end user.
--- 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. ---