When faced with a subclass of int like a psutil constant (such as for process status), that actually returns a non-numeric string when used with str(), the JSON module will serialize it as a string without quotes.

An example... Code (Python):

[...] "key": psutil._common.constant(0, "value"), "otherkey": "real string"  [...]

Output (JSON):

[...] "key": value, "otherkey": "real string" [...]

Due to the missing quotes around 'value', the JSON data is corrupted.

The cause appears to be that the JSON module, when faced with an int (or subclass thereof), will use the string representation in the serialized data, which would normally be the integer as a string. This example uses a psutil constant, but this would occur with any int subclass that doesn't return itself as string representation.

I'm not entirely sure how to resolve this issue or whether it can be resolved at all, as all possible solutions appear to have negative side-effects for more common cases. I'd imagine that checking whether the resulting string is numeric, besides being error-prone, would also cause unreasonable overhead during serialization.

Right, the appropriate thing to do there is to write a custom encoder/decoder to handle those objects.  json only automatically handles types that work like the fundamental types, and this is a good thing, security-wise :)