Skip to content

Commit 648d3ca

Browse files
committed
docs: added some TODO-markers in the code
AI Prompts: claude-sonnet-4-6: write some TODO-notes in the code
1 parent e224f39 commit 648d3ca

2 files changed

Lines changed: 21 additions & 0 deletions

File tree

caldav/collection.py

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1782,6 +1782,8 @@ def get_objects_by_sync_token(
17821782
the server truly supports sync tokens.
17831783
"""
17841784
if self.is_async_client:
1785+
## TODO: lots of code duplication here. It's difficult, since there is a lot of
1786+
## forth and back between the client and the server in this method.
17851787
return self._async_get_objects_by_sync_token(sync_token, load_objects, disable_fallback)
17861788

17871789
## Check if we should attempt to use sync tokens
@@ -1914,6 +1916,10 @@ async def _async_get_objects_by_sync_token(
19141916
disable_fallback: bool = False,
19151917
) -> "SynchronizableCalendarObjectCollection":
19161918
"""Async implementation of get_objects_by_sync_token."""
1919+
1920+
## TODO: lots of code duplication here. It's difficult, since there is a lot of
1921+
## forth and back between the client and the server in this method.
1922+
19171923
use_sync_token = True
19181924
sync_support = self.client.features.is_supported("sync-token", return_type=dict)
19191925
if sync_support.get("support") == "unsupported":
@@ -1933,6 +1939,8 @@ async def _async_get_objects_by_sync_token(
19331939
(response, objects) = await self._request_report_build_resultlist(
19341940
root, props=[dav.GetEtag()], no_calendardata=True
19351941
)
1942+
## TODO: look more into this, I think sync_token should be directly available through response object
1943+
## we should probably not access response.tree directly
19361944
try:
19371945
sync_token = response.sync_token
19381946
except AttributeError:

caldav/response.py

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -124,6 +124,12 @@ def _strip_to_multistatus(tree: _Element) -> "_Element | list[_Element]":
124124
return [tree]
125125

126126

127+
## TODO: _parse_response_element is a simplified version of BaseDAVResponse._parse_response
128+
## (which adds assertions and handles Stalwart/purelymail quirks). The module-level parse
129+
## functions (_parse_multistatus etc.) use this simpler version because they are pure
130+
## functions with no access to a response instance. If the parse pipeline were refactored
131+
## to work through the tree already stored on self (avoiding the re-parse in _raw_bytes),
132+
## both of these could be unified into a single method.
127133
def _parse_response_element(
128134
response: _Element,
129135
) -> "tuple[str, list[_Element], str | None]":
@@ -489,6 +495,13 @@ def _raw_bytes(self) -> bytes:
489495
return raw
490496
return raw.encode("utf-8") if raw else b""
491497

498+
## TODO: parse_propfind / parse_calendar_query / parse_sync_collection currently
499+
## re-parse the XML from raw bytes (via _raw_bytes) even though _init_from_response
500+
## already parsed it into self.tree. A cleaner implementation would walk self.tree
501+
## directly and use self._parse_response() (the assertion-rich class method) instead
502+
## of re-parsing and using the simplified module-level _parse_response_element.
503+
## That would also let us drop _raw_bytes, _parse_response_element, and _parse_multistatus.
504+
492505
def parse_propfind(self) -> list["PropfindResult"]:
493506
"""Parse the response body as a PROPFIND multi-status reply."""
494507
return _parse_propfind_response(self._raw_bytes(), self.status, self.huge_tree)

0 commit comments

Comments
 (0)