openvax / topiary / 33413852945

93%

push

github

Let callers correct read_lens's binding-column map (#211) (#213)

* Let callers correct read_lens's binding-column map (#211)

The mapping tables were private and read_lens took no mapping argument,
so a consumer hitting an unmapped or mis-mapped binding column had to
wait for a topiary release. That absence is why #208 blocked a
downstream consumer outright rather than being a local workaround.

binding_metrics merges over the built-in table rather than replacing it,
and can correct a built-in mapping as well as fill a gap. Keys are
(tool, metric) -- the pair the unmapped-column warning already names,
and version-free, since a mapping keyed on the raw column name would
break on a version spelling change, which is what #206 removed.

Values are validated up front: an unknown kind or field would emit a
wide-form name from_wide cannot read, so the data would reach the frame
and vanish on to_long(). None declares a non-prediction column --
silencing the warning without remapping, and without deleting it.

16 tests in tests/test_lens_binding_override.py. Version 5.30.0.

Claude-Session: https://claude.ai/code/session_01BAUqjqDDPXaTdtUDJqapJG

* Address review: refuse overrides that build an unreadable frame

The review found the feature's own documented use case corrupting the
frame. score_ba already maps to (affinity, score) for netmhcpan, so
redirecting aff_nm there put two identically named columns in the frame:
pandas allows it, one set of values becomes unreachable, and to_long()
raises "Expected a 1D array". That is #208's shape, reintroduced by the
thing meant to help work around it. My test passed on the corrupt frame
because it only asserted column presence.

Two source columns claiming one output name is now refused, naming both
columns and the name they collided on. Unlike a version collision there
is no "keep both": it is the same predictor's same field either way.

Also from the review:

- the unmapped warning now names the (tool, metric) key... (continued)

63 of 63 new or added lines in 2 files covered. (100.0%)

5651 of 6203 relevant lines covered (91.1%)

2.73 hits per line