AI-Written Python: When a JSON Export Contains a Number JSON Cannot Read

A creator asks an AI assistant to write a Python export for a weekly campaign dashboard. Most rows have a conversion rate. One campaign has no recorded visits, so the script uses a special floating-point value, NaN, to mark an unavailable calculation. The file saves successfully. The dashboard refuses to import it. The export looked finished because the script wrote a file, but it never checked whether the receiving tool could read the contents.

There are two decisions hiding in that failure. One is technical: which tokens can appear in a standard JSON document? The other belongs to the person who owns the report: what should a reader see when a rate cannot be calculated? Fixing the first without settling the second can produce a file that imports smoothly and tells the wrong story.

What Python accepts and what JSON allows

The JSON specification, RFC 8259, published in December 2017, excludes NaN and infinities from its number grammar. The Python standard library documentation describes a difference in its default behaviour: its JSON module can emit and accept the bare tokens NaN, Infinity and -Infinity. A round trip through the same module can therefore succeed even though a strict reader would reject the file.

For a concrete example, json.dumps({'rate': float('nan')}) produces a document containing "rate": NaN. With allow_nan=False, the same export raises ValueError. That setting is a useful check at the point where Python writes the output. It tells you there is a value to deal with; it does not decide how your dashboard should represent an unavailable rate.

Keep the scope of that check clear. It catches the special floating-point values at serialisation, but it does not prove the file meets the receiving application’s field rules. A dashboard might accept a JSON document and still refuse a field that has the wrong type. Test those two boundaries separately, so a passing file check does not hide a failing import.

Give unavailable values an explicit meaning

In the campaign example, a rate of zero could mean that 100 people visited and none converted. No recorded visits leaves the rate undefined for a different reason. Replacing both with zero erases the distinction. Quoting the token as "NaN" makes it a string, but the receiving tool may be expecting a number or a null value. Only use a representation that both sides have agreed to interpret.

One possible design is to export null for an unavailable rate and include a separate reason such as ‘no visits recorded’, if the receiving format allows it. In Python, None serialises to JSON null. Another design is to hold the row for review when an unavailable calculation signals missing data. For example, a campaign that has not started and one that has stopped reporting may look alike in the rate field, but the next action is different.

Our article on empty and missing fields in CSV imports tackles the corresponding decision at the input boundary. Here the question is what the output promises. If a downstream tool treats an omitted field differently from a field explicitly set to null, choose deliberately between those two representations. Do not let a convenient clean-up step make that decision for you.

Follow the value one step further if another report uses this export. A dashboard might leave an unavailable rate blank in a table but quietly treat it as zero when calculating an average. Decide which campaigns qualify for that average and make the rule visible. If the metric is conversions divided by visits across all campaigns, check the underlying counts as well. A file can preserve the distinction correctly while a later calculation throws it away.

Check the export before replacing the previous file

Ask an AI coding assistant to produce examples with a normal rate, a genuine zero and an unavailable calculation. If the script handles data from several sources, include a case where a special value appears inside a nested record. Run the export against those examples and inspect what the receiving application actually shows. The zero should still mean zero, and the unavailable result should remain distinguishable when someone reads the report.

• Use strict serialisation to catch non-finite values before publishing the file. If writing to disk, validate the complete candidate before replacing the last good export.
• Test the receiving tool or a validator that uses the same field rules. A syntactically valid file can still violate the agreed shape or type of a field.
• When the export fails, make the report name, affected field and next step visible to the person who can correct the source. Avoid logging the whole record if a short reference is enough.

If the receiving application cannot show why a value is unavailable, choose whether to display a clear note elsewhere or hold that row out with an explanation. A silently omitted campaign can be as misleading as one shown with a zero rate. Check what readers infer from the finished dashboard, especially if they use it to compare campaigns or choose where to investigate.

A useful instruction for the next AI-written export is: ‘Show how you represent an unavailable calculation, preserve a real zero, and prove the destination can import both.’ That ties the technical rule to the purpose of the report. A successful export should deliver something the next tool can read and the next person can interpret.

Sources

• IETF, RFC 8259, section 6: Numbers, December 2017.
• Python standard library documentation, JSON: Infinite and NaN Number Values, consulted 6 November 2026.