GayathriSrividya commented on PR #3454:
URL: https://github.com/apache/iceberg-python/pull/3454#issuecomment-4619944443

   > Thanks for the coordination note. Happy to defer to the maintainers on 
which approach lands.
   > 
   > To summarise the trade-off for the review:
   > 
   > **#3416 (iterator semantics):** Changes return types to 
`Iterator[Identifier]` across all catalog implementations. Clean interface but 
is a breaking change — callers using `len()`, slicing, `in`, or converting to 
list implicitly will need updates.
   > 
   > **#3454 (PaginationList):** Keeps `list[Identifier]` return type (backward 
compatible). Subclasses `list` so all existing callers work unchanged. Lazy 
fetching happens transparently during iteration.
   > 
   > If maintainers prefer the iterator direction from #3416, I'm happy to 
close this PR. If PaginationList's backward-compatibility is valued, I can 
rebase onto whatever #3416 lands on and focus only on the REST pagination piece.
   > 
   > Whatever the decision, closing is fine — the important thing is that #3365 
gets resolved.
   
   Thanks Yuya for the coordination note, and thanks @stark256-spec for laying 
out the trade-off clearly.
   
   From my side, the main intent of #3416 was to address #3365 by making 
pagination explicit through iterator semantics across catalog list operations. 
I agree this is a larger API change than returning a list-like wrapper, but I 
think the benefit is that it makes the lazy behavior clearer to callers and 
avoids pretending the full result set is already materialized.
   
   That said, I also understand the compatibility advantage of #3454. If 
maintainers prefer preserving the current `list[Identifier]` contract, I’m 
happy to coordinate and make sure the relevant parts of #3416, especially the 
page-by-page REST fetching/retry behavior, are carried over cleanly.
   
   So I’m flexible on the final direction, but my preference is still the 
explicit iterator approach unless backward compatibility is the deciding 
factor. Either way, I agree we should avoid duplicate implementations and 
converge on one solution for #3365.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to