rob/CampervanHomeAssistant
Watch
1
0
Fork
You've already forked CampervanHomeAssistant
 0
Code Issues Pull requests Projects Releases 26 Packages Wiki Activity Actions

Lift a shared known() lookup for the IntEnum fallback pattern #99

Merged
Claude merged 1 commit from refactor/enum-lookup-helper into refactor/code-hygiene 2026-09-28 06:53:23 +00:00
Conversation 1 Commits 1 Files changed 9 +52 -35
Claude commented 2026-09-28 06:52:22 +00:00
Collaborator

Five places each did the same try/except of looking a raw int up in an
IntEnum, falling back when unknown: word_for in alarms.py, mode_of,
kind_of, semantic_of, node_name, and _result_name in the updater.

Adds protocol/enums.py with known(enum, raw) -> E | None (stdlib only,
since the updater mounts protocol/ alone), plus word() for the
name-or-raw-int case word_for covered. Each of the five now expresses
itself as a one-liner over known. word_for moves out of alarms.py since
it was never alarm-specific; its four importers (alarms, lockout, select,
binary_sensor) now pull word from protocol.enums instead.

No behaviour change — existing tests are the gate, all green under
tools/check.

Five places each did the same try/except of looking a raw int up in an IntEnum, falling back when unknown: `word_for` in alarms.py, `mode_of`, `kind_of`, `semantic_of`, `node_name`, and `_result_name` in the updater. Adds `protocol/enums.py` with `known(enum, raw) -> E | None` (stdlib only, since the updater mounts `protocol/` alone), plus `word()` for the name-or-raw-int case `word_for` covered. Each of the five now expresses itself as a one-liner over `known`. `word_for` moves out of alarms.py since it was never alarm-specific; its four importers (alarms, lockout, select, binary_sensor) now pull `word` from `protocol.enums` instead. No behaviour change — existing tests are the gate, all green under `tools/check`.
Lift a shared known() lookup for the IntEnum fallback pattern
All checks were successful
Lint, type check and test / hassfest (pull_request) Successful in 22s
Details
Lint, type check and test / quality (pull_request) Successful in 2m0s
Details
Lint, type check and test / release (pull_request) Has been skipped
Details
7570f537dd
Claude merged commit cbc0f7d58a into refactor/code-hygiene 2026-09-28 06:53:23 +00:00
Claude deleted branch refactor/enum-lookup-helper 2026-09-28 06:53:23 +00:00
Claude reviewed 2026-09-28 06:54:31 +00:00
Claude left a comment

Reviewed (note: PR was already merged by the time this review ran).

Checked all five call sites against their original try/except behaviour — known() is used with an explicit is None/is not None check everywhere, so there's no falsy-zero trap even though several enum members (e.g. AlarmState.CLEARED = 0, PresentationKind/SemanticClass members at 0) sit at value 0.

  • word() in protocol/enums.py reproduces word_for exactly (name-or-raw fallback), and all four importers (alarms.py, lockout.py, select.py, binary_sensor.py) were updated — no leftover word_for references anywhere (grepped the whole tree).
  • mode_of, kind_of, semantic_of, node_name, _result_name are each faithful one/two-liners over known(), preserving their original fallback value and public signature.
  • protocol/enums.py imports only enum.IntEnum — stdlib-only, safe for the updater's standalone mount of protocol/.
  • IntEnum import stays in alarms.py (still used by AlarmState/Severity), so nothing unused there.
  • Diff is scoped exactly to the 9 files named in the task; no touches to coordinator.py or any entity/platform pass-through methods, so no overlap with concurrent work there.
  • Tabs, British English, docstring style all match the surrounding files; PEP 695 generic syntax (def known[E: IntEnum]) is fine since pyproject.toml targets py314.

Couldn't get a clean ./tools/check run to completion — the review worktree was removed mid-run (looks like it was cleaned up once the PR merged). The partial run before that showed lint/format/types green, but a batch of test failures/errors spread across files this PR doesn't touch at all (test_manifest, test_release, test_stamp_build, test_firmware_updates, etc.), which points to a pre-existing environment issue rather than something this change caused. Worth a clean run in CI to confirm, but nothing in the diff itself looks like the cause.

No blocking findings.

Reviewed (note: PR was already merged by the time this review ran). Checked all five call sites against their original try/except behaviour — `known()` is used with an explicit `is None`/`is not None` check everywhere, so there's no falsy-zero trap even though several enum members (e.g. `AlarmState.CLEARED = 0`, `PresentationKind`/`SemanticClass` members at 0) sit at value 0. - `word()` in `protocol/enums.py` reproduces `word_for` exactly (name-or-raw fallback), and all four importers (alarms.py, lockout.py, select.py, binary_sensor.py) were updated — no leftover `word_for` references anywhere (grepped the whole tree). - `mode_of`, `kind_of`, `semantic_of`, `node_name`, `_result_name` are each faithful one/two-liners over `known()`, preserving their original fallback value and public signature. - `protocol/enums.py` imports only `enum.IntEnum` — stdlib-only, safe for the updater's standalone mount of `protocol/`. - `IntEnum` import stays in `alarms.py` (still used by `AlarmState`/`Severity`), so nothing unused there. - Diff is scoped exactly to the 9 files named in the task; no touches to `coordinator.py` or any entity/platform pass-through methods, so no overlap with concurrent work there. - Tabs, British English, docstring style all match the surrounding files; PEP 695 generic syntax (`def known[E: IntEnum]`) is fine since `pyproject.toml` targets `py314`. Couldn't get a clean `./tools/check` run to completion — the review worktree was removed mid-run (looks like it was cleaned up once the PR merged). The partial run before that showed lint/format/types green, but a batch of test failures/errors spread across files this PR doesn't touch at all (test_manifest, test_release, test_stamp_build, test_firmware_updates, etc.), which points to a pre-existing environment issue rather than something this change caused. Worth a clean run in CI to confirm, but nothing in the diff itself looks like the cause. No blocking findings.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rob/CampervanHomeAssistant!99
No description provided.