Skip to content
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

fix: improper types in pagers generation #970

Merged
merged 3 commits into from Sep 29, 2021

Conversation

dpcollins-google
Copy link
Contributor

@dpcollins-google dpcollins-google requested a review from a team as a code owner August 16, 2021 15:32
@google-cla google-cla bot added the cla: yes This human has signed the Contributor License Agreement. label Aug 16, 2021
Copy link
Contributor

@tseaver tseaver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change is correct, if a bit nit-picky (Iterable is a less restrictive contract than Iterator, and a strict superset). Do we have cases where type-checking actually complains about the difference? I guess that would be clients calling next(thing) directly?

@dpcollins-google
Copy link
Contributor Author

dpcollins-google commented Aug 16, 2021

The change is correct, if a bit nit-picky (Iterable is a less restrictive contract than Iterator, and a strict superset). Do we have cases where type-checking actually complains about the difference? I guess that would be clients calling next(thing) directly?

This is not quite correct. Iterables are not required to have __next__ methods, they only usually do :) https://docs.python.org/3/library/collections.abc.html#collections.abc.Iterable

In fact, you can see this with <*>Pager itself: it is an Iterable (with __iter__) but not an Iterator (no __next__)

@busunkim96
Copy link
Contributor

@dpcollins-google could you update the golden files? That should resolve the one failing Tests / integration check. See instructions here.

@tseaver
Copy link
Contributor

tseaver commented Aug 16, 2021

@dpcollins-google I think we are in violent agreement here: Iterable requires only __iter__, while Iterator must also have __next__ which is a) more restrictive than Iterable, and b) makes the contract for Iterator a "sub-type" of Iterable (no types which implement Iterator do not also implement Iterable).

At any rate, my question remains: do we have reported errors from pytype in this repo, or even in the wild, where declaring the less-restrictive type (Iterable) is causing errors? My surmise is that either in this repo or elsewhere, somebody is using next(response), rather than for foo in response:.

@busunkim96
Copy link
Contributor

It looks like this is causing a problem for Pub/Sub (see log, so I'm inclined to merge it now and re-visit if it causes an issue.

@software-dov @atulep Could you also take a look as the generator owners?

@dpcollins-google
Copy link
Contributor Author

dpcollins-google commented Sep 29, 2021

To clarify, the issue this is causing is that PyType detects that its wrong: the pager object itself is NOT an Iterator because its __iter__ method doesn't return an Iterator, it returns an Iterable, which doesn't have a __next__ method defined.

@atulep
Copy link
Contributor

atulep commented Sep 29, 2021

From https://docs.python.org/3/library/typing.html#typing.Generator, generator can have a return type of either Iterable or Iterator. Why is this change needed?

Does Pub/Sub fail because a caller of the pager expects an iterator instead of iterable?

@dpcollins-google
Copy link
Contributor Author

Please see my comment above. The Pager itself does not model Iterable because its __iter__ method states incorrectly that it returns an Iterable when it needs to return an Iterator.

@atulep atulep self-requested a review September 29, 2021 19:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes This human has signed the Contributor License Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants