-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-architect Iterator class. #2531
Conversation
Intended to hold and slice up state that has already been retrieved from the server.
This is so that the owned items iterator management could be done on the base class and the child classes just need to worry about converting the JSON values to whatever type is required.
This state can never happen since a StopIteration will occur before the method would ever be called without a token.
Also doing a tiny re-org in constructor to separate the attributes which change and those which don't.
Making JSON API call helpers non-public. This reduces the interface to methods relevant to iterating.
6d50cf6
to
d9824c6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My one concern is how a service like datastore will work.
This abstraction seems to completely hides cursors, but cursors often need to be passed between client and server in datastore (think client-side pagination). I'm wondering how that would fit in here?
"""The :class:`Page` is an iterator.""" | ||
return self | ||
|
||
def _item_to_value(self, item): |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
return self._num_items | ||
|
||
@property | ||
def remaining(self): |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
Datastore has it's own specialized Though a "next step" would be to make the iterator support gRPC / GAPIC generated classes, so we may be able to tackle datastore there. (Just not in this PR.) |
Sorry I haven't responded on this @dhermes. I don't have much feedback though. You actually just answered the question I did have.
|
LGTM |
This is to lower the burden on implementers. The previous approach (requiring a Page and Iterator subclass) ended up causing lots of copy-pasta docstrings that were just a distraction. Follow up to googleapis#2531.
Re-architect Iterator class.
This is to lower the burden on implementers. The previous approach (requiring a Page and Iterator subclass) ended up causing lots of copy-pasta docstrings that were just a distraction. Follow up to googleapis#2531.
This is to lower the burden on implementers. The previous approach (requiring a Page and Iterator subclass) ended up causing lots of copy-pasta docstrings that were just a distraction. Follow up to #2531.
This PR should definitely reviewed commit-by-commit.
Primary changes are:
Page
base-class for iterating over a single page of a result set