adopt-project.py and scripts/repo_shape.py: a float that overflows is said as "the number inf", and a plain integer of more than 4300 digits ends check and execute in a ValueError traceback instead of yaml-unparsable (RV1198's NIT-1 and NIT-2 on #1198, both older than it; follows #1114) #1212

(lane openRepoShape-4, 2026-10-23T18:00:03Z)

Found by: RV1198 and RV1198-cont, the independent review of PR #1198 (for #1114) at d38e4e36 (#1198 issuecomment-6365427244, #1198 (comment)). It graded #1198 READY, with no MUST and no SHOULD, and three NITs. NIT-1 and NIT-2 predate #1198, are equally true on main, and need follow-up issues: they are this issue. The third NIT is about #1198's body alone and is not part of it. This follows #1114 and #1198.

The measurements below are RV1198-cont's, taken through check and execute on a scratch merge of #1198's head with main 961640c68 (Python 3.12.3, where sys.get_int_max_str_digits() is 4300; the review says CI's 3.14 has the same default), with the real gh kept unreachable. The probe is RV1198's probe_bigint.py (<clone> <fresh base dir>), and its output is in the lane's scratch, rv1198/probe/bigint-120609.txt. #1198 is open and not on main. Line numbers are approximate, read on main ac5f28d2a (2026-10-23): _read_as is at adopt-project.py about :8371, and _scalar and load_yaml at scripts/repo_shape.py about :580 and :1321. The reader is scripts/repo_shape.py, and #1198 changes none of it (0 diff lines).

I also ran the reader alone on main ac5f28d2a's scripts/repo_shape.py (Python 3.12.3, parse_yaml("k: <value>\n")), to see that both still hold there:

4300 digits   -> int 1111111111...
4301 digits   -> raised ValueError  Exceeds the limit (4300 digits) for integer string conversion: value has 4301 digits; use sys.set_int_max_str_digits() ...
400 ones .5   -> float inf
300 nines .5  -> float 1e+300

What is wrong

NIT-1: a float that overflows is said as "the number inf", a number this reader would never read

_scalar reads -?\d+\.\d+ with float(text), so a decimal that overflows is inf, and one of 300 digits is 1e+300. _read_as says a number with {value!r}, so:

• a commit: of four hundred 1s followed by .5, in check and in execute, on the merge: records `commit:` as the number inf, which is not text. The probe's float-overflow-commit row: check exit 1, execute exit 2, FINDING plan-pin-malformed, no traceback, no gh call.
• a commit: of three hundred 9s followed by .5 reads "the number 1e+300" (RV1198's probe).
• This reader reads inf and 1e+300 as text, never as numbers, so "the number inf" names a value no plan holds: it stands for every float that overflows, and typing inf into the plan gives the text inf. On main, before adopt-project.py: _pin_row_problem says a pin field whose value is not text as _read_as says what the plan's reader read, "records commit: as the number 7", where it spelled it as Python does, commit: 7 and True, so check and execute name it in the words the plan's other refusals use under the same plan-pin-malformed (#1114) #1198, the same values read as commit: inf (Python's repr in _pin_row_problem).
• Fix, the review's: have _scalar refuse a decimal whose float is not finite, as yaml-unparsable. Then have _read_as say a float in a form this reader reads back as that number, with no exponent and no inf, in place of repr.

NIT-2: a plain integer of more than 4300 digits ends check and execute in a ValueError traceback

_scalar's int(text) raises ValueError: Exceeds the limit (4300 digits) for integer string conversion, and load_yaml catches only YamlError, so nothing turns it into a refusal. From the probe, on the merge:

• Every row: gh-calls=0 and remotes-made=False. So the fault is in the reader, not the pin rows, and it ends the run before anything is asked or made.
• 4300 digits is an ordinary finding, as it should be. The line is at 4301.
• Fix, the review's: catch the ValueError in _scalar and raise a YamlError that names the line, so that it is yaml-unparsable. (A fix that counts digits before int() would do as well. What matters is that a plan in which the reader cannot make a number is a refusal and not a traceback, at any int_max_str_digits setting.)

The probe, in the part that matters (the rows are built from a plan planned(...) wrote, with pins: [] replaced):

def pin(commit):
    return ("pins:\n  - product: openGlass\n    repository: opensoft/openGlass\n"
            f"    commit: {commit}\n    tree_sha256: \"{DIGEST}\"\n"
            "    digest_source: gh-api-tree-recursive\n")
rows = {
    "int-4301-digits-commit": text.replace("\npins: []\n", "\n" + pin("1" * 4301), 1),
    "int-4300-digits-commit": text.replace("\npins: []\n", "\n" + pin("1" * 4300), 1),
    "float-overflow-commit": text.replace("\npins: []\n", "\n" + pin("1" * 400 + ".5"), 1),
    "int-4301-digits-outside-pins": text + "probe_extra: " + "1" * 4301 + "\n",
}
# each row: check --plan P --local-remote-dir D ; execute --plan P --local-remote-dir D --yes --work-dir W

Done when

• A commit: of 4301 digits, and a top-level key of 4301 digits, end check and execute in a yaml-unparsable refusal that names the line, with no traceback; 4300 digits is still the plan-pin-malformed finding.
• A commit: of 1 * 400 + .5 is refused by _scalar, or _read_as says it without inf and without an exponent, and 9 * 300 + .5 without 1e+300.
• The pin rows' wording adopt-project.py: _pin_row_problem says a pin field whose value is not text as _read_as says what the plan's reader read, "records commit: as the number 7", where it spelled it as Python does, commit: 7 and True, so check and execute name it in the words the plan's other refusals use under the same plan-pin-malformed (#1114) #1198 puts in (records `commit:` as the number 7, which is not text) is unchanged for a number the reader reads as itself.

See #1114 and #1198.

Lane: openreposhape-4 (openRepoShape-4)