Parse exponent-form numbers with extreme mantissas

[rtibblesbot]

Summary

extract_value returned None for exponent-form numbers whose mantissa repr uses exponent notation (0.00001e5, 12345678901234567e2), dropping those answers in _process_input_answers.

• parse_exponent calls float() on the {mantissa}e{exp} string instead of eval on a string built from str(float).
• No number_parser.js exists here, so there is no JS side.

Closes #6228

References

• [QTI] Numeric answer validation doesn't match xsd:double and differs between inline and headless validation #6150, Older-Kolibri Perseus export drops QTI Text entry items whose numeric answers are valid xsd:double but not parseable by extract_value #6224, [QTI] Tracking issue -- UX enhancements #6103

Reviewer guidance

• Overflow (1e400) still returns inf, as before; no isfinite guard was added. Add one if None is wanted.
• Underflow (1e-400) stays 0.0; add a zero-result check if it should be None.
• Tests use lowercase e; if Older-Kolibri Perseus export drops QTI Text entry items whose numeric answers are valid xsd:double but not parseable by extract_value #6224 lands first, add uppercase rows.

AI usage

Implemented with Claude Code using TDD; new rows were run red against the old parser first. I reviewed the diff and ran test_parser.py.

🤖 Generated with Claude Code

Committed separately: no commit on this branch introduced the lines these changes touch, so they are a new commit rather than folded into the work they amend:

• contentcuration/contentcuration/utils/parser.py

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

• Ran pre-flight CI checks (lint, format, tests) and verified all pass
• Rebased onto the target branch and resolved any conflicts
• Reorganized commit history into clean, logical commits
• Audited the diff to ensure only issue-relevant files are changed
• Built PR body from the repository's PR template with evidence blocks

🟡 Waiting for feedback Last updated: 2026-09-30 20:20 UTC

[rtibbles]

One question about conflicting updates.

[rtibbles]

This feels redundant with this? #6209

Once the above is merged, will we even need this parser any more?

[rtibblesbot]

Not redundant: #6209 doesn't replace utils/parser.py. Its new code imports extract_value from it (searched the #6209 diff: 1 import, 1 call). Non-test callers on this branch: perseus.py:78 and parser.py itself (parse_exponent, percent parsing) — 3 places, all use the fixed parse_exponent. So extract_value stays after #6209 and these rows still test it. No changes made.