Repository navigation
Per-venue trading calendars and extension points for venues and data addresses (2.11.0) - #40
Merged
Merged
Conversation
Each listing is now judged by its own venue's hours. Before, every listing was judged by the simulation's calendar, so on an hourly run clocked on Moscow an American ETF counted as tradeable at 10:01 Moscow (03:01 in New York) and the order failed with CannotOrderDelistedAsset. - ziplime.utils.venue_calendars: MIC -> calendar table, a FORTS calendar built on XMOS, clock_calendar_name() for a run that spans venues (24/5 when their hours differ), ZIPLIME_VENUE_CALENDARS overrides. - ExchangeAsset.trading_calendar; BarData asks the listing's venue (by session day on a daily run, by minute intraday). - rebalance() leaves a leg alone while its market is shut, instead of failing the run on the first such bar. - The no-price error names the closed venue and both calendars. - algopack://market/dataset[/granularity] mounts and context.algopack_dataset(), adapted to the DataSource API that takes a trading calendar. New extra: ziplime[algopack] (moexalgo). Single-market backtests are unchanged. Ported from the 1.20.9 build the backtesting service has run since September, with its tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…and addresses The Moscow-specific parts of the previous commit belong in zipfinam, the Russian-market extension, not in the core: - AlgoPack is removed from ziplime (connector, algopack_dataset(), the algopack extra and its tests). zipfinam ships it. - The FORTS calendar and the MISX/RTSX venues are removed from the venue table. zipfinam registers them. What stays is the engine mechanism and two ways for an extension to plug in: - ziplime.utils.venue_calendars: register_venue_calendars() / unregister_venue_calendars(), and the ziplime.venue_calendars entry point group, loaded on first lookup. Precedence: shipped table < extensions < ZIPLIME_VENUE_CALENDARS. - ziplime.data.data_sources.address_schemes: register_address_scheme() and the ziplime.address_schemes entry point group. _resolve_named_data_source mounts scheme://... through it; hf:// stays built in. Extensions no longer need to patch TradingAlgorithm. Installing an extension is enough; nothing has to import it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
arbuzovv
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes
Each listing is now judged by its own venue's hours, so one backtest can hold instruments from markets that keep different hours. Extensions can now add venues, calendars and
scheme://data addresses without patching the engine. Version bumped to 2.11.0; release notes are inrelease-notes.md.ziplime.utils.venue_calendarsclock_calendar_name()gives one clock for a run that spans venues:24/5when their hours differ,24/7when one never closes.ZIPLIME_VENUE_CALENDARSoverrides the table.ExchangeAsset.trading_calendar.BarData._venue_is_openasks the listing's own venue: by session day on a daily run, by minute intraday.rebalance()leaves a leg alone while its market is shut. Before, the run failed on the first such bar.register_venue_calendars()/unregister_venue_calendars(), and theziplime.venue_calendarsentry point group, loaded on first lookup. Precedence: shipped table, then extensions, then the environment override.ziplime.data.data_sources.address_schemes:register_address_scheme(scheme, mount)and theziplime.address_schemesentry point group._resolve_named_data_sourcemountsscheme://...through it;hf://stays built in.Single-market backtests are unchanged.
Where it comes from
The per-venue mechanism is the part of the 1.20.9 build that the backtesting service has run in production since September and that 2.10.3 lacks. It was ported by three-way merge against
a283eadf, the commit that build branched from, with its tests.Verified
pytest testswith all extras: 1228 passed, 2 xfailed, nothing failing. New tests:tests/data/test_address_schemes.py, plus the extension tests intests/utils/test_venue_calendars.py.The last row is the regression this fixes.
To release
Merge into dev, then into master. Then push a
v2.11.0tag:publish-to-pypi.ymlpublishes on tags. zipfinam 1.26.10.1 requiresziplime>=2.11.0, so release this first.🤖 Generated with Claude Code