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

❌ 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.