On Wednesday, June 10, 2020, at 10:37 -0500, Chris Angelico wrote:
On Thu, Jun 11, 2020 at 1:35 AM Eric V. Smith email@example.com wrote:
On 6/10/2020 11:00 AM, Chris Angelico wrote:
On Thu, Jun 11, 2020 at 12:45 AM Dan Sommers 2QdxY4RzWzUUiLuE@potatochowder.com wrote:
If you control both the producers and the consumers, and they're both written in Python, then you may as well use pickle and base64 (and an HMAC!) to convert your python data to an opaque ASCII string and just transmit that string. Why bother with JSON and all of its verbosity and restrictions in the first place?
If interoperability is a concern, then how much does this sort of thing complicate your JSON and all of the other producers/consumers? Will their applications, standard libraries, and best practices "just work"?
What if it's to be produced and consumed by your app (so, no interoperability), but you want it to be human-readable and human-editable? JSON is pretty good for that.
Readable, yes. Mostly.
Both reading and writing definitely get worse, however, as soon as you have to add your own type annotations and sub-structures. Then again, I used to read/write/edit assembly language programs happily with ed, so all of this is fairly subjective.
True, but I don't think the stdlib needs to cater to that requirement when there are hooks to write your own customizations.
I agree in general, but it might be worth having a few recipes in the docs or something. Make it clear that the Python json module *can* encode these kinds of things, but it's up to you as the app designer to decide how (among a number of equally viable options) you want to represent them.
Hooks and non-trivial examples in the documentation are both excellent.