Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Know when icalendar_instance was modified

Open
  • Is something wrong?
#761 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend, databases

Research direction

Start by reading the linked icalendar#1914 proposal and caldav issue #613 to understand the dependency and the existing DataState design. Then inspect IcalendarState and the data access and save paths; the issue gives no file or test names. Done means safely detecting modifications, caching serialization, and skipping unchanged saves while accounting for in-place list mutations and the vobject path.

Written by the indexing model from the issue text.

Description

enhancement

Disclaimer: AI-generated text below the line, generated by Claude Opus 5.5 (Claude Code), from the prompts:

Have a look at https://github.com/collective/icalendar/issues/1914 - how could this help us in this library?
Make an issue in the caldav tracker, but make it clear that it depends on #1914 [collective/icalendar#1914] and that it has low priority.

Low priority. Blocked on https://github.com/collective/icalendar/issues/1914, which is an open proposal and not implemented yet.

Since https://github.com/python-caldav/caldav/issues/613, a CalendarObjectResource keeps its data in a DataState. In IcalendarState, caldav cannot know whether the user has changed the icalendar.Calendar it handed out, so get_data() calls to_ical() again on every call, and save() cannot tell an unchanged object from a changed one.

icalendar#1914 proposes a ComponentFactory that is also used for parsing, plus Component.convert_to(factory). With it, caldav could parse into its own subclasses of icalendar.Event/Todo/Journal (and Calendar) that override __setitem__, __delitem__, pop and update to mark the object as modified. I checked this against icalendar 7.3.1.dev188 with a Todo subclass: writes through the typed properties all go through those methods (summary, status, DUE, DURATION, DTSTART, categories = [...], add(), del). In-place changes such as categories.append(...) do not.

What it would allow:

  • IcalendarState.get_data() could cache the serialised string and drop the cache on a write, so it would not call to_ical() on every read.
  • save() could skip a write, or log one, when nothing was changed.
  • The objects that come out of recurrence expansion (recurring-ical-events) would keep the subclass if r-i-e uses the same factory. That is what collective/icalendar#1914 is meant for.

Limits:

  • In-place mutation of returned lists is not seen, so a snapshot comparison is still needed as a fallback before trusting "unchanged".
  • It depends on icalendar sending every write through those dict methods. That is true today, but it is an implementation detail, and icalendar would have to promise it.
  • isinstance(x, icalendar.Event) still holds for a subclass, so user code is not affected, but it raises caldav's minimum icalendar version.
  • The vobject path gets nothing from this.

The same approach has been chosen for change tracking in https://github.com/pycalendar/calendaring (see open question 13 in docs/design/API_DESIGN.md). If it works there, caldav can follow.

Dominant language
Python
Stars
412
Forks
113
Avg merge
1d 7h
Merged PRs (30d)
34

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from python-caldav/caldav

All issues in python-caldav/caldav

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.