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.

Title: Add a COMPACT constant to the json module
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.7
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: bob.ippolito Nosy List: andrewnester, benhoyt, berker.peksag, bob.ippolito, brett.cannon, eric.smith, ezio.melotti, methane, r.david.murray, rhettinger, serhiy.storchaka
Priority: normal Keywords:

Created on 2017-03-20 22:33 by brett.cannon, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 72 closed andrewnester, 2017-03-20 22:34
Messages (12)
msg289905 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2017-03-20 22:33
In issue #29540 there was a suggestion to add a `compact` argument to json.dump() and json.dumps(). That was eventually rejected as adding complexity to an API that's already messy.

But in GH-72 someone created a COMPACT constant to the json module which gets a similar effect as a `compact` argument but without expanding any APIs. Unfortunately I think the constant proposal got lost in discussion of adding the `compact` argument, so I'm opening a new issue to make a final decision as to whether we should accept/reject the COMPACT constant idea.
msg289906 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2017-03-20 23:14
+1: gets the job done without complicating the API.
msg289910 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-03-21 04:06
-1 We already have a way to do it.  I teach this way in my Python courses and there is a zero learning curve. It isn't difficult at all.
msg289912 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-03-21 04:51
Actually, only put me down for -0.  This isn't a necessary change but it isn't egregious either.
msg289921 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2017-03-21 07:10
-0.  COMPACT_SEPARATOR make more sense to me.
Because `ensure_ascii=False` may make JSON more compact too.
msg289923 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-03-21 07:28
-0 too. This complicates the module API without a need.
msg289942 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2017-03-21 15:59
I suppose I'm +0. I don't think this is particularly useful, but this is closer to the ideal of just having a boolean option. We should probably also plan to remove the documentation for what the type of separators is to give the impression that COMPACT and the default are the only valid options.
msg291053 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2017-04-03 05:31
+1. See msg287773 for my reasoning.
msg293557 - (view) Author: Andrew Nester (andrewnester) * Date: 2017-05-12 16:23
any conclusion on this? looks like it's a bit stuck
msg293564 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-05-12 19:27
Having mulled this over for a while, I'm disinclined to go forward with this proposal.  On the one hand, it is a relatively small change, so it doesn't affect the overall complexity much.  However, API design principles suggest that this isn't the right thing to do.

Good APIs tend to steer users towards correct design.  I'm concerned that adding a COMPACT constant will suggest to users that compacting separators in the output is something they should be doing.  Instead, it is a distracting micro-optimization that rarely saves much space but comes at a cost of readability (it is no fun to have to read JSON without spaces).

For other kinds of code generation, minification is normally a post-processing step rather than something incorporated into the generator itself.  When we care about the size of JSON, we really want people to use compression rather than feebly editing-out a few spaces.

The main reason to have the *separators* argument is to factor-out hardwired behavior.  It wasn't really about binary choices: normal-vs-thin, readable-vs-smushed.

Lastly, I don't really like having two-ways-to-do-it.  We already have something that works, so should have we should have a preference for documenting what we have rather than leaning towards continuous slow sprawl with new options that aren't backwards compatible (creating yet another cross-version maintenance issue).
msg293567 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-05-12 19:45
Note also that using separators=COMPACT doesn't guarantee the most compact output. As Inada mentioned ensure_ascii=False may make JSON more compact. And you shouldn't use non-default indent!

I don't understand effort spent for this issue. Even if add json.COMPACT you could use it only with 3.7+. And adding a named constant in your program is just one line!
msg293624 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2017-05-13 19:49
Obviously Bob can re-open this if he disagrees with the general sentiment against this idea, but since I doubt he will disagree I'm going to save him some effort and close this issue.

Thanks to Andrew for taking the time to writing the PR and being patient while we discussed this.
Date User Action Args
2022-04-11 14:58:44adminsetgithub: 74049
2017-05-13 19:49:20brett.cannonsetstatus: open -> closed
resolution: rejected
messages: + msg293624

stage: resolved
2017-05-12 19:45:31serhiy.storchakasetmessages: + msg293567
2017-05-12 19:27:16rhettingersetmessages: + msg293564
2017-05-12 16:23:52andrewnestersetnosy: + andrewnester
messages: + msg293557
2017-04-03 05:31:56berker.peksagsetnosy: + berker.peksag
messages: + msg291053
2017-03-21 15:59:47bob.ippolitosetmessages: + msg289942
2017-03-21 07:28:44serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg289923
2017-03-21 07:10:30methanesetnosy: + methane
messages: + msg289921
2017-03-21 04:51:13rhettingersetmessages: + msg289912
2017-03-21 04:06:20rhettingersetassignee: bob.ippolito

messages: + msg289910
nosy: + bob.ippolito
2017-03-20 23:14:51eric.smithsetnosy: + eric.smith
messages: + msg289906
2017-03-20 22:34:11andrewnestersetpull_requests: + pull_request657
2017-03-20 22:33:53brett.cannonsetnosy: + r.david.murray, benhoyt
2017-03-20 22:33:19brett.cannoncreate