#591 (the strict arithmetic convention) is the core of milestone 3 and it's finished — code complete, CI green everywhere. It's been sitting unreviewed for two months, not because anything is wrong with it, but because a change this size is genuinely hard to review well in one pass.
It isn't really 6000 lines of logic. The actual source change is about 500 lines across expressions.py, variables.py, common.py and config.py. The rest is tests (~2700) and doc notebooks (~2800). So this is a packaging problem, not a code problem.
PyPSA just shipped a local workaround for this in PyPSA/PyPSA#1677 — a silent ramp-limit bug that put a capacity-expansion result 47% off with no error. Downstream stays exposed until we release v1, so it's worth pushing now.
Proposal: split #591 into a small stack. Almost nothing gets rewritten — each PR just lifts what's already in #591 onto master.
- Spec + bug catalog. A short markdown doc stating the problem and the v1 convention, plus test_legacy_violations.py (the ~23 known silent bugs, written against current behaviour so they pass on master). This is where we actually discuss and agree the convention.
- Config + test harness. The arithmetic_convention option, the deprecation warning class, conftest and markers, the property/convention test files. All inert — v1 tests are xfail until step 3, default stays legacy.
- The convention. The ~500 lines of logic. Lands v1 behaviour and flips the xfails green.
- Docs. The four notebooks.
On release: v1 ships opt-in and experimental, legacy stays the default and stays silent (no deprecation warnings yet). That keeps step 3 a safe merge and lets PyPSA/calliope try v1 and give feedback before we commit. Deprecation warnings and the default flip come later.
The convention should also take #703 into account — its reindex/shift/fill_value coverage overlaps with the v1 absent-slot rules, so the two need to line up.
#591 stays open as the source until step 3 merges, then closes. #550 is superseded by the strict matching and can close once we agree the spec. Open questions like #627 get settled in step 1.
I'll start on the spec doc.
#591 (the strict arithmetic convention) is the core of milestone 3 and it's finished — code complete, CI green everywhere. It's been sitting unreviewed for two months, not because anything is wrong with it, but because a change this size is genuinely hard to review well in one pass.
It isn't really 6000 lines of logic. The actual source change is about 500 lines across expressions.py, variables.py, common.py and config.py. The rest is tests (~2700) and doc notebooks (~2800). So this is a packaging problem, not a code problem.
PyPSA just shipped a local workaround for this in PyPSA/PyPSA#1677 — a silent ramp-limit bug that put a capacity-expansion result 47% off with no error. Downstream stays exposed until we release v1, so it's worth pushing now.
Proposal: split #591 into a small stack. Almost nothing gets rewritten — each PR just lifts what's already in #591 onto master.
On release: v1 ships opt-in and experimental, legacy stays the default and stays silent (no deprecation warnings yet). That keeps step 3 a safe merge and lets PyPSA/calliope try v1 and give feedback before we commit. Deprecation warnings and the default flip come later.
The convention should also take #703 into account — its
reindex/shift/fill_valuecoverage overlaps with the v1 absent-slot rules, so the two need to line up.#591 stays open as the source until step 3 merges, then closes. #550 is superseded by the strict matching and can close once we agree the spec. Open questions like #627 get settled in step 1.
I'll start on the spec doc.