This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author anders.rundgren.net@gmail.com
Recipients anders.rundgren.net@gmail.com, barry, bob.ippolito, eli.bendersky, ethan.furman, ncoghlan, rhettinger
Date 2014-12-30.05:43:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1419918199.54.0.527142130319.issue23123@psf.upfronthosting.co.za>
In-reply-to
Content
Ethan Furman added the comment:

> I am not a regular json user, but my impression is the format is
> pretty  basic, and we would be overloading it to try and keep numbers
> with three decimal places as Decimal, and anything else as float.

> Isn't json's main purpose to support data exchange between different
> programs of different languages?  Not between different Python
> programs?

Right, unfortunately the need to support non-native data types like big decimals, dates and blobs have lead to a certain amount of confusion and innovation among JSON tool designers.

I (FWIW) do actually NOT want to extend a single bit from the RFC, I just want serializing to be "non-invasive".   If the parse_float option stays "as is" it seems that both the people who want big (non-standard) numbers and I who want somewhat non-standard serialization would be happy.  I.e. a documentation snippet would be sufficient as far as I can tell.

Serialization order of objects is apparently a hot topic
https://code.google.com/p/v8/issues/detail?id=164
but Python has no problem with that.
History
Date User Action Args
2014-12-30 05:43:19anders.rundgren.net@gmail.comsetrecipients: + anders.rundgren.net@gmail.com, barry, rhettinger, bob.ippolito, ncoghlan, eli.bendersky, ethan.furman
2014-12-30 05:43:19anders.rundgren.net@gmail.comsetmessageid: <1419918199.54.0.527142130319.issue23123@psf.upfronthosting.co.za>
2014-12-30 05:43:19anders.rundgren.net@gmail.comlinkissue23123 messages
2014-12-30 05:43:18anders.rundgren.net@gmail.comcreate