Add a COMPACT constant to the json module

[brettcannon]

BPO	29863
Nosy	@brettcannon, @rhettinger, @etrepum, @ericvsmith, @ezio-melotti, @bitdancer, @methane, @benhoyt, @berkerpeksag, @serhiy-storchaka, @andrewnester
PRs	bpo-29863: Add json.COMPACT constant #72

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/etrepum'
closed_at = <Date 2017-05-13.19:49:20.809>
created_at = <Date 2017-03-20.22:33:18.983>
labels = ['3.7', 'type-feature', 'library']
title = 'Add a COMPACT constant to the json module'
updated_at = <Date 2017-05-13.19:49:20.807>
user = 'https://github.com/brettcannon'

bugs.python.org fields:

activity = <Date 2017-05-13.19:49:20.807>
actor = 'brett.cannon'
assignee = 'bob.ippolito'
closed = True
closed_date = <Date 2017-05-13.19:49:20.809>
closer = 'brett.cannon'
components = ['Library (Lib)']
creation = <Date 2017-03-20.22:33:18.983>
creator = 'brett.cannon'
dependencies = []
files = []
hgrepos = []
issue_num = 29863
keywords = []
message_count = 12.0
messages = ['289905', '289906', '289910', '289912', '289921', '289923', '289942', '291053', '293557', '293564', '293567', '293624']
nosy_count = 11.0
nosy_names = ['brett.cannon', 'rhettinger', 'bob.ippolito', 'eric.smith', 'ezio.melotti', 'r.david.murray', 'methane', 'benhoyt', 'berker.peksag', 'serhiy.storchaka', 'andrewnester']
pr_nums = ['72']
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue29863'
versions = ['Python 3.7']

[brettcannon]

In issue bpo-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.

[ericvsmith]

+1: gets the job done without complicating the API.

[rhettinger]

-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.

[rhettinger]

Actually, only put me down for -0. This isn't a necessary change but it isn't egregious either.

[methane]

-0. COMPACT_SEPARATOR make more sense to me.
Because ensure_ascii=False may make JSON more compact too.

[serhiy-storchaka]

-0 too. This complicates the module API without a need.

[etrepum]

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.

[berkerpeksag]

+1. See msg287773 for my reasoning.

[andrewnester]

any conclusion on this? looks like it's a bit stuck

[rhettinger]

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).

[serhiy-storchaka]

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!