New handler for list results #285
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
whyscream
force-pushed
the
278-new-list-handler
branch
from
975c50f to
2fc3eb8
Compare
whyscream
force-pushed
the
278-new-list-handler
branch
3 times, most recently
from
96548cf to
11f0fcc
Compare
added 3 commits
June 20, 2023 12:31
The current result list wrapping class `ObjectList` is intended for list handling,
but supports a mix of list- and dictionary-related protocols: iteration, slices,
getitem (by key, not by position), etc.
One feature that you'd expect from a list that isn't supported, is getting quickly
from the start to the end of the list. You need to use a combination of `.has_next()`
and `.get_next()` to work through all (paginated) list items.
The old `Objectlist` supports key-based access to its members, but since the data is
paged, you can never be sure that the data is actually available in this page, or in
the next/previous one). Getting list length is also supported, but it only returns
the length of the current page, not a grand total. Both features are treacherous.
To improve on this, a new simple iterator-based approach was used, which transparently
fetches additional paginated data from the API. Things like `getitem` and `len()` are
no longer available, if you need these, they're easy to implement in custom code:
```python
payments = client.payments.list()
length = 0
for item in payments:
length += 1
# Equivalent of payments["tr_12345"]
if item.id == "tr_12345":
break
# Equivalent of len(payments)
print(length)
# An even better replacement for getting a specific payment would be:
client.payments.get("tr_12345")
```
TODO:
- More tests
- Reversed() iterator, hoe does it work?
- Add logic to return an ResultListIterator where now an ObjectList is hardcoded
- Empty list results?
whyscream
force-pushed
the
278-new-list-handler
branch
from
11f0fcc to
4eaf710
Compare
Contributor
Author
|
After the work in #333 , we need to see what parts of this work are still relevant. Replacing |
Contributor
Author
|
Idea from mollie/mollie-api-php#701, add a separate |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A heavily simplified class to wrap the results of
.list()calls. Has cleaner code, implements autopagination handling, and no more features that actually shouldn't be there. See commit message for details.This should solve #278