Summary
It would be useful to support .json as an optional output format for the data_regression fixture, with YAML remaining the default.
Motivation
Some projects work primarily with JSON-native data — REST API payloads, configuration schemas, serialization round-trips, and so on — and storing regression baselines in the same format feels natural. An extension parameter on data_regression.check, similar to how file_regression already accepts one, could provide that flexibility without touching any existing behaviour.
Rough sketch of the API
# existing behaviour, unchanged
data_regression.check(data)
# opt in to JSON
data_regression.check(data, extension=".json")
The JSON baseline would be serialized with json.dumps using sorted keys and readable indentation, keeping the same diff-friendly properties as the current YAML output.
Notes
One subtlety worth being aware of: json.dumps(sort_keys=True) only sorts top-level dict keys, not dicts nested inside lists. A recursive pre-sort step before serialization would be needed to guarantee stable output in all cases.
Summary
It would be useful to support
.jsonas an optional output format for thedata_regressionfixture, with YAML remaining the default.Motivation
Some projects work primarily with JSON-native data — REST API payloads, configuration schemas, serialization round-trips, and so on — and storing regression baselines in the same format feels natural. An
extensionparameter ondata_regression.check, similar to howfile_regressionalready accepts one, could provide that flexibility without touching any existing behaviour.Rough sketch of the API
The JSON baseline would be serialized with
json.dumpsusing sorted keys and readable indentation, keeping the same diff-friendly properties as the current YAML output.Notes
One subtlety worth being aware of:
json.dumps(sort_keys=True)only sorts top-level dict keys, not dicts nested inside lists. A recursive pre-sort step before serialization would be needed to guarantee stable output in all cases.