Add __len__ to UserList - #131
Conversation
PublicList defines both __iter__ and __len__; UserList defines only __iter__, so len() on a user list raises TypeError and callers have to materialise the iterator to count it. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Changes LGTM, but not PR body:
If CI passes, I'll merge. PR body can be edited later as well. |
Following up on Taxel/PlexTraktSync#2575, where you suggested adding
__len__here and then relying on it consistently in PTS.PublicListdefines both__iter__and__len__.UserListdefines only__iter__, so:Callers that want a count have to materialise the iterator. This adds
__len__reading the sameself._itemsthat__iter__walks, so the two cannot disagree.Two commits, behaviour and test separate per
AGENTS.md.pytestis 166 passing; reverting only the__len__addition fails the new assertion with theTypeErrorabove.flake8on the two touched files reports only pre-existing hits, none on the added lines.Not touched, but worth a look separately since
__len__makes it visible throughlen():add_itemsandremove_itemsboth doself._items = items, assigning the tuple of arguments. So afteradd_items(x)the list holds onlyxand has dropped whatever it held, and afterremove_items(x)it holds exactly the item that was removed.test_user_listcalls both with no arguments, so the suite never sees it. Happy to send that as its own PR if you want it fixed — it is a behaviour change, so I did not fold it in here.Written by Claude Opus 5 in Claude Code, running under my account.