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.

classification
Title: Improve code readability of json.tool
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: berker.peksag, dhimmel, r.david.murray, rhettinger
Priority: normal Keywords:

Created on 2017-07-19 19:52 by dhimmel, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 2720 closed dhimmel, 2017-07-19 19:52
Messages (4)
msg298686 - (view) Author: Daniel Himmelstein (dhimmel) * Date: 2017-07-19 19:52
In https://github.com/python/cpython/pull/2720, I propose code changes to the json.tool command line utility. These changes are entirely non-functional and instead focus on improving code readability, style, brevity, extensibility, and maintainability.

These changes mainly came up during the implementation of two enhancements of json.tool:

+ https://github.com/python/cpython/pull/345 to add indentation / whitespace options (bpo-29636).

+ https://github.com/python/cpython/pull/201 to display non-ascii characters (bpo-27413).

These issues and pull requests are currently awaiting further consensus around their design and desirability. Therefore, I wanted to separate the non-functional code improvements from these PRs into a distinct PR.

This has the benefit of allowing the future enhancement PRs to focus solely on adding features rather than the readability changes.
msg298691 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-07-19 22:06
However, our general policy is that we don't make such changes unless we are also touching the code for other reasons.  So I think using this PR as a base for your feature PRs, and then committing everything together if they are accepted, would be the way to go.  I don't know if it would work to actually use it as a base for the other PRs in github, or if it would work better to just make it the initial commit in a commit series.  The github workflow is too new for us to have definite answers to such questions :)
msg298692 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2017-07-19 22:21
I don't think most of the changes improve readability of json.tool. Everyone has their own preferences and it's usually not enough to justify code churn.

Also, we don't need to add comments when the code itself is pretty descriptive:

    # Output JSON
    with options.outfile as outfile:
        json.dump(obj, outfile, sort_keys=options.sort_keys, indent=4)
        outfile.write('\n')

IMO, the only acceptable change is the correct use of 'default' parameter for 'infile' and 'outfile'.
msg298820 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-07-21 19:51
I concur with the other commenters and am marking this as closed.

Thank you for the effort to contribute.  May I suggest working on one the many open bug reports.
History
Date User Action Args
2022-04-11 14:58:49adminsetgithub: 75154
2017-07-21 19:51:14rhettingersetstatus: open -> closed

nosy: + rhettinger
messages: + msg298820

resolution: rejected
stage: patch review -> resolved
2017-07-19 22:21:50berker.peksagsetnosy: + berker.peksag
messages: + msg298692

type: enhancement
stage: patch review
2017-07-19 22:06:11r.david.murraysetnosy: + r.david.murray
messages: + msg298691
2017-07-19 19:52:56dhimmelcreate