Numeric answers with a very small or very large mantissa and an exponent are not parsed by `extract_value`

[rtibblesbot]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Target branch: unstable

Observed behavior

parser.extract_value returns None for exponent-form numbers whose mantissa's Python repr uses exponent notation, i.e. < 1e-4 or >= 1e16.

• 0.00001e5 → None (mantissa 1e-05 builds eval("1e-05e5"), a SyntaxError swallowed as None)
• 12345678901234567e2 → None
• 100000000000000000000E-19 → None

0.0001e5 and 1e-5 parse. All of the above are valid finite xsd:double values (#6150).

Expected behavior

Any finite exponent-form number the pattern accepts parses to its value.

User-facing consequences

• Perseus export for older Kolibri: _process_input_answers drops the answer, so the item ships "answers": [] and cannot be answered (Older-Kolibri Perseus export drops QTI Text entry items whose numeric answers are valid xsd:double but not parseable by extract_value #6224 normalises +5/1E3 but cannot help these).
• Legacy input_question items with such answers are dropped in the same way.

Steps to reproduce

1. from contentcuration.utils.parser import extract_value
2. extract_value("0.00001e5") → None; expected 1.0.

Context

• Related: [QTI] Tracking issue -- UX enhancements #6103, Older-Kolibri Perseus export drops QTI Text entry items whose numeric answers are valid xsd:double but not parseable by extract_value #6224, [QTI] Numeric answer validation doesn't match xsd:double and differs between inline and headless validation #6150
• parse_exponent in contentcuration/contentcuration/utils/parser.py builds a string from str(float) and evals it.
• parser.py mirrors number_parser.js; check whether the JS side has the same gap.

AI usage

Found while reviewing the #6224 branch with Claude Code; reproduced by running extract_value on both upstream/unstable and the branch.

[rtibblesbot]

Plan: extract_value parses every finite exponent-form number EXPONENT accepts, including mantissas whose repr uses exponent notation.

• Parse extreme-mantissa exponents without eval
• /simplify pass and self-review

Assumptions — the issue did not settle these; say so if one is wrong.

• Overflow (1e400) returns None, not inf; if inf is wanted, drop the isfinite guard.
• Underflow (1e-400) stays 0.0; if it should be None, add a zero-result check.
• The E examples are tested with 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 the uppercase rows.

---

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

How was this generated?

• Implemented code following the pre-approved plan using test-driven development (red-green-refactor)
• Ran the project's full test suite and linter before committing
• For UI changes: captured live screenshots to verify rendering
• For backend changes: verified with example API/CLI output