Problem
Calendar.load(...) rebuilds calendars on every call, even when the same named source is loaded repeatedly. That now affects packaged calendars as well as the optional provider integrations (PMC/, XCAL/, WORK/).
Refined scope
- Add an internal cache for repeated
Calendar.load(name=...) calls.
- Cover packaged calendars and the existing named providers:
ANBIMA, B3, Actual
PMC/<calendar>
XCAL/<calendar>
WORK/<code>
- Keep
filename=... loads out of the initial cache scope to avoid stale-file invalidation complexity.
- Preserve behavior safety: the cache must not leak shared mutable
Calendar instances across callers.
- Keep the NumPy-backed and legacy loaders aligned.
Acceptance notes
- Repeated named loads should avoid reparsing or rebuilding from the source.
- A caller mutating a returned calendar object must not affect later loads.
- Tests will likely need an internal cache reset helper, but that does not need to be part of the public API.
list_calendars() is discovery only; this issue is about load-time reuse.
Problem
Calendar.load(...)rebuilds calendars on every call, even when the same named source is loaded repeatedly. That now affects packaged calendars as well as the optional provider integrations (PMC/,XCAL/,WORK/).Refined scope
Calendar.load(name=...)calls.ANBIMA,B3,ActualPMC/<calendar>XCAL/<calendar>WORK/<code>filename=...loads out of the initial cache scope to avoid stale-file invalidation complexity.Calendarinstances across callers.Acceptance notes
list_calendars()is discovery only; this issue is about load-time reuse.