I have not asked for means to serialize invalid JSON objects. Yes, with the "raw" output, you can create invalid JSON, but it does not mean you have to. Let's take a look at it from a different POV and focus on the original problem. Imagine this situation, I have a JSON string with this value: ``` msg2 = '{"val": 1.0000000000000000000000000000000000000000000000000000000000001}' ``` This is perfectly valid JSON representation of the float. I can parse it with standard module with default float handling and get this: ``` json:orig = {"val": 1.0000000000000000000000000000000000000000000000000000000000001} json:pyth = {'val': 1.0} json:seri = {"val": 1.0} ``` i.e Python chooses to represent it as 1.0 (which I guess is the closest to the original value) and then serialize it as such into the output. But I can use `parse_float=decimal.Decimal` option of the standard module and get this (with the custom encoder encoding it into the string): ``` dson:orig = {"val": 1.0000000000000000000000000000000000000000000000000000000000001} dson:pyth = {'val': Decimal('1.0000000000000000000000000000000000000000000000000000000000001')} dson:seri = {"val": "1.0000000000000000000000000000000000000000000000000000000000001"} ``` There is nothing wrong with the float in the original JSON and there is nothing wrong with representing that float with decimal.Decimal type either. What is missing is just corresponding encoder support. I want to be able to serialize the Decimal object into its JSON float form, not into a string or some custom map. Which is exactly what happens with `simplejson` and `use_decimal=True` set: ``` sjson:orig = {"val": 1.0000000000000000000000000000000000000000000000000000000000001} sjson:pyth = {'val': Decimal('1.0000000000000000000000000000000000000000000000000000000000001')} sjson:seri = {"val": 1.0000000000000000000000000000000000000000000000000000000000001} ``` And this is what is missing in the current implementation and there seems to be different ways how to address it, as Angelo pointed out. At the moment standard module basically does not allow creating a perfectly valid JSON float which does not have valid binary representation, while at the same time, allows decoding such a float (without a precision loss with the decimal.Decimal). This is the asymmetry I am talking about. Why the output should be limited by underlying implementation, while the input is not?