Christopher, I understood that the risk of producing invalid JSON if custom type is allowed to serialize into output stream seems to be a major problem for many. This has been already mentioned in this discussion. However, I thought it was related to the original idea of "raw output" (for generic custom user type - which could serialize into arbitrary JSON type).
Since we agreed that the only type which needs such a treatment is JSON fractional number, it should not be that hard to check if the custom type output is valid. I had a look at how current 'json' module implementation handles the JSON numbers on decode. There is a regex defined in scanner.py (NUMBER_RE) which is used to recognize JSON number in the input stream. If the regex matches it matches into three groups conveniently parsed as 'integer', 'frac' and 'exp'. If either 'frac' or 'exp' is not empty, the decoder decodes the JSON input as a float (if default decoding is used) or as <parse_float> type if this one is set. decoder.py defines (in the source comment) JSON number with either 'exp' or 'frac' part as "JSON real number" and one without either as "JSON integer number". So I gues I should have written in my previous post "JSON real number" instead of "JSON fractional number", to be perfectly aligned with current implementation nomenclature. I have not verified if the NUMBER_RE regex defined in scanner.py matches exactly JSON number syntax or there are some deviations, but I would say it would be good start for checking the custom type output - by the rule, if the decoder lets this in, then the encoder should let it out. The check will involve only the custom type specified by 'dump_as_float', so it should not impact the default use and for those who would want to use custom type, it would be acceptable price to pay for the flexibility they get. If the check based on the same regex will be accepted, it will ensure that what will get in, will be also able to get out (in exactly same form) on one side and on the other side, if there were some decimal.Decimal outputs which current 'json' would reject in decode, the custom type output sanity check (even if the custom type was decimal.Decimal) will not let those values into the output either. This type of consistency seems to be worthy the performance impact of the additional check for me. Apart from that I am not aware of any other adverse impact of the additional sanity check. _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/ZCZ3TNML6RMKQT3MDCHHDCC2UAT5FZJG/ Code of Conduct: http://python.org/psf/codeofconduct/
