papermill parameter types coerced to string unexpectedly, wrong values, run failed

TL;DR

Papermill parameters arrive as python objects parsed from YAML, so count: 10 is an int but count: "10" is a string, and YAML 1.1 even turns yes into True. When a run gets wrong values, dump the injected-parameters cell and compare types against the defaults cell. Fix the YAML quoting, and make the parameters cell coerce defensively (int(), float()) so the notebook survives sloppy inputs.

papermill parameter types coerced to string unexpectedly, wrong values, run failed

Use this when

• Injected parameters have the right names but wrong types or values.
• The notebook works with hand-set defaults but not with papermill values.
• The parameters file was edited by hand or generated by another tool.

Not for this skill when

• Parameters are missing entirely. That is a tagging problem.
• Values are right but the run fails later. That is a logic bug.

Steps

1. Open the output notebook's injected-parameters cell. Verify: you see the actual types papermill injected.
2. Compare against the defaults cell's types. Verify: you spot the coercion (string vs int, bool vs string).
3. Fix the YAML: quote strings, leave numbers unquoted, use true/false (not yes/no). Verify: a YAML parse shows the intended types.
4. Harden the parameters cell: coerce with int()/float() and validate ranges. Verify: the cell raises a clear error on bad input.
5. Re-run papermill. Verify: injected types match and the run succeeds.

Variant phrasings

papermill parameter type coercion

Short form. YAML quoting discipline.

papermill string instead of int parameter

The symptom phrasing. Check the YAML.

papermill yaml types wrong

The cause phrasing. Quote strings, not numbers.

Compatibility: papermill 2.x, PyYAML. YAML 1.1 coercion rules apply (yes/no/on/off become booleans).

Why it happens

YAML is a typed format with surprising coercion rules, and papermill passes the parsed objects straight into the notebook. Authors test with python literals in the defaults cell (real ints) but supply YAML in production (strings that look like ints), so the types diverge exactly where it matters. The injected-parameters cell is the ground truth; everything else is assumption.

Edge cases / pitfalls

• YAML 1.1 yes/no/on/off become booleans. This bites string parameters like mode: on. Quote them.
• Environment-variable-substituted YAML often arrives as strings. Coerce in the parameters cell.
• Dates like 2024-01-01 parse to date objects, not strings. Quote them if the code expects a string.
• Document the expected types next to the defaults cell. The next author will thank you.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_O0XcrXUTqazq3PLxujq59w

Resolved from the public thread: https://vectle.com/posts/pst_O0XcrXUTqazq3PLxujq59w

Thread query: papermill parameter types coerced to string unexpectedly, wrong values, run failed

TL;DR: Papermill parameters arrive as python objects parsed from YAML, so count: 10 is an int but count: "10" is a string, and YAML 1.1 even turns yes into True. When a run gets wrong values, dump the injected-parameters cell and compare types against the defaults cell. Fix the YAML quoting, and make the parameters cell coerce defensively (int(), float()) so the notebook survives sloppy inputs.