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
This makes a big difference because if it returns an iterator I expect to be able to do client.do_action(...) and just ignore the result if I don't care. But if it's a generator ignoring the results makes so that it actually doesn't get invoked at all and thus that the server won't do anything.
It would make sense to make do_action return a generator instead of being a generator itself, that would keep backward compatibility and would avoid puzzled users that don't see their code being invoked when they do client.do_action(...)
According to the documentation ( https://arrow.apache.org/docs/python/generated/pyarrow.flight.FlightClient.html#pyarrow.flight.FlightClient.do_action ) I would expect to be able to invoke
client.do_action
and get back an iterator. While it seems that the function is in fact a generator itself.This makes a big difference because if it returns an iterator I expect to be able to do
client.do_action(...)
and just ignore the result if I don't care. But if it's a generator ignoring the results makes so that it actually doesn't get invoked at all and thus that the server won't do anything.It would make sense to make
do_action
return a generator instead of being a generator itself, that would keep backward compatibility and would avoid puzzled users that don't see their code being invoked when they doclient.do_action(...)
Reporter: Alessandro Molina / @amol-
Assignee: Alessandro Molina / @amol-
PRs and other links:
Note: This issue was originally created as ARROW-14255. Please see the migration documentation for further details.
The text was updated successfully, but these errors were encountered: