-
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
Moving backend specific behavior from Page to Iterator. #2545
Conversation
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.
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.
This looks good to me with one minor thing.
def next(self): | ||
"""Get the next value in the iterator.""" | ||
item = six.next(self._item_iter) | ||
result = self._item_to_value(item) | ||
result = self._parent._item_to_value(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.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
SGTM On Fri, Oct 14, 2016 at 2:40 PM Danny Hermes notifications@github.com
|
[ | ||
<MyItemClass at 0x7fea740abdd0>, | ||
<MyItemClass at 0x7fea740abe50>, | ||
] |
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.
blob._set_properties(item) | ||
return blob | ||
|
||
def _update_page(self): |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
The previous implementation may catch users off guard since the iterator.page access may also update the value before access. In addition, this PR removed the _update_page() / next_page() subclass behavior in _BlobIterator. Over-riding that method was never intended. Instead makes a non-public class attribute _PAGE_CLASS that can be replaced with Page subclasses. This can be revisited if more implementations require custom behavior on Page creation / Page.__init__.
@jonparrott PTAL |
if self.has_next_page(): | ||
response = self._get_next_page_response() | ||
self._page = self.PAGE_CLASS(self, response) | ||
if self._page is NO_MORE_PAGES: |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
I'm pretty okay with the combination of page is None and not has_next_page() On Fri, Oct 14, 2016, 5:17 PM Danny Hermes notifications@github.com wrote:
|
Alternatively, why does |
Also renaming next_page() to update_page() on Iterator and dropping any return value from that method. Also throwing an AttributeError if the page is unset on @Property access.
This is because Iterator.page combined with Iterator.update_page() can provide the same thing and has_next_page() is really an implementation detail. Done via: $ git grep -l has_next_page | > xargs sed -i s/has_next_page/_has_next_page/g
@jonparrott PTAL. I did what we discussed out-of-band yesterday. Instead of using |
@dhermes, why the name change from |
@daspecster Because |
@dhermes yeah I guess I was confused by this example https://github.com/GoogleCloudPlatform/google-cloud-python/pull/2545/files#diff-1e128fc6c096e8635aabf4ba0c484200R90. |
@daspecster Let's continue design discussion in #2548 |
Moving backend specific behavior from Page to Iterator.
This is to lower the burden on implementers. The previous approach (requiring a
Page
andIterator
subclass) ended up causing lots of copy-pasta docstrings that were just a distraction.Follow up to #2531.