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: per_page param #63

Merged
merged 1 commit into from
Jun 5, 2024
Merged

Fix: per_page param #63

merged 1 commit into from
Jun 5, 2024

Conversation

angela-tran
Copy link
Member

Closes #61

@angela-tran angela-tran self-assigned this Jun 4, 2024
Copy link

github-actions bot commented Jun 4, 2024

Coverage report

Click to see where and how coverage changed

FileStatementsMissingCoverageCoverage
(new stmts)
Lines missing
  littlepay/api
  client.py
  products.py
Project Total  

This report was generated by python-coverage-comment-action

@angela-tran
Copy link
Member Author

@thekaveman In _get_list, do you think we should remove perPage from the params dict if per_page was passed in as a kwarg?

def _get_list(self, endpoint: str, **kwargs) -> Generator[dict, None, None]:
params = dict(page=1, perPage=100)
params.update(kwargs)

@thekaveman
Copy link
Member

@thekaveman In _get_list, do you think we should remove perPage from the params dict if per_page was passed in as a kwarg?

Yeah that's a good question. I'm not super happy with all these duplicated per_page all over the place either. Maybe a different approach is to invert the logic, use per_page by default in _get_list and pass in the override perPage on the (I think only one??) endpoint it is needed.

It sounds like they are trying to normalize these and so hopefully soon we won't have to worry about the different versions.

As to your actual question, I don't think it's a problem to send both, and we can save ourselves a few cycles by not worrying about removing it / writing tests etc.

@angela-tran
Copy link
Member Author

@thekaveman In _get_list, do you think we should remove perPage from the params dict if per_page was passed in as a kwarg?

Yeah that's a good question. I'm not super happy with all these duplicated per_page all over the place either. Maybe a different approach is to invert the logic, use per_page by default in _get_list and pass in the override perPage on the (I think only one??) endpoint it is needed.

It sounds like they are trying to normalize these and so hopefully soon we won't have to worry about the different versions.

As to your actual question, I don't think it's a problem to send both, and we can save ourselves a few cycles by not worrying about removing it / writing tests etc.

That all makes sense. I can make those changes, thanks for the suggestions 👍

@thekaveman
Copy link
Member

@angela-tran I merged #62 so if you want to rebase on main to get that one as well 👍 🙏

@angela-tran angela-tran marked this pull request as ready for review June 4, 2024 20:15
@angela-tran angela-tran requested a review from a team as a code owner June 4, 2024 20:15
@angela-tran angela-tran changed the title Fix: per_page param for certain endpoints Fix: per_page param Jun 4, 2024
Copy link
Member

@thekaveman thekaveman left a comment

Choose a reason for hiding this comment

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

Nice!

@angela-tran angela-tran merged commit 0adb981 into main Jun 5, 2024
3 checks passed
@angela-tran angela-tran deleted the fix/per-page-param branch June 5, 2024 16:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactor API paging parameter name
2 participants