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 [email protected] or file a JIRA ticket
with INFRA.
---
