[issue29636] Specifying indent in the json.tool command
Change by Daniel Himmelstein : -- pull_requests: +16961 pull_request: https://github.com/python/cpython/pull/17482 ___ Python tracker <https://bugs.python.org/issue29636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22454] Adding the opposite function of shlex.split()
Daniel Himmelstein added the comment: I am interested in shlex.join as a way to log subprocess.CompletedProcess.args as a string that users could run in their terminals. I initially assumed that this was also the scope of shlex.join. However, it seems that shlex.join does not accept all types of command arguments supported by subprocess, such as pathlib.Path objects. Should shlex.join support an split_command list that includes pathlib.Path objects and any other types supported by subprocess? -- nosy: +dhimmel ___ Python tracker <https://bugs.python.org/issue22454> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34898] add mtime argument to gzip.compress
Daniel Himmelstein added the comment: Any reason not to also expose mtime in the gzip.open API? -- nosy: +dhimmel ___ Python tracker <https://bugs.python.org/issue34898> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29636] Specifying indent in the json.tool command
Daniel Himmelstein added the comment: Since opening this issue, I've encountered several additional instances where indentation control would have been nice. I don't agree that jq is a sufficient substitute: 1. jq is generally not pre-installed on systems. For projects where users are guaranteed to have Python installed (but may be on any operating system), it is most straightforward to be able to just use a python command and not have to explain how to install jq on 3 different OSes. 2. jq does a lot more than prettifying JSON. The simple use case of reformatting JSON (to/from a file or stdin/stdout) can be challenging. 3. json.tool describes itself as a "simple command line interface to ... pretty-print JSON objects". Indentation is an essential aspect of pretty printing. Why even have this CLI if we're unwilling to add essential basic functionality that is already well supported by the underlying json.dump API? Python excels at APIs that match user needs. It seems like we're a small change away from making json.tool flexible enough to satisfy real-world needs. So I'm in favor of merging PR 9765 or PR 345. I'm happy to do the work on either to get them mergeable based on whatever specification we can agree on here. -- ___ Python tracker <https://bugs.python.org/issue29636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18943] argparse: default args in mutually exclusive groups
Change by Daniel Himmelstein : -- pull_requests: +5593 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue18943> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32160] lzma documentation: example to XZ compress file on disk
Daniel Himmelstein added the comment: > we could consider an API addition Just brainstorming here... perhaps an API addition would be most appropriate in the shutil module (https://docs.python.org/3.6/library/shutil.html) which already contains shutil.make_archive and shutil.unpack_archive. One could imagine shutil.compress and shutil.decompress that took a format argument to specify the compression type. -- ___ Python tracker <https://bugs.python.org/issue32160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32160] lzma documentation: example to XZ compress file on disk
Change by Daniel Himmelstein : -- assignee: -> docs@python components: +Documentation nosy: +docs@python type: -> enhancement ___ Python tracker <https://bugs.python.org/issue32160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32160] lzma documentation: example to XZ compress file on disk
New submission from Daniel Himmelstein : The documentation for the lzma module currently contains 6 examples (https://docs.python.org/3.6/library/lzma.html#examples). However, it does not include an example to XZ compress a file on disk. The functionality I'm envisioning would be similar to the command: ```sh xz --compress --keep path ``` I believe this is possible in python with: ```python with open(in_path) as in_file, lzma.open(out_path, 'w') as out_file: shutil.copyfileobj(in_path, out_file) ``` Note gzip has a similar example (https://docs.python.org/3.6/library/gzip.html#examples-of-usage). Compressing an existing file on disk is a use case I commonly encounter. Python is ideal for the task because it provides a cross-platform solution that doesn't require installing additional command line utilities. Before finding shutil.copyfileobj, I assumed memory-efficient on-disk XZ compression was not possible in Python, due to its omission from the docs. I'm happy to propose example code for the documentation. Alternatively, if this feature is considered useful, we could consider an API addition to provide a one-line command for on-disk compressing/decompressing files. Since this would be a major addition that should be consistent across compression modules, perhaps we should just start with a lzma doc example? -- components: IO messages: 307163 nosy: dhimmel priority: normal severity: normal status: open title: lzma documentation: example to XZ compress file on disk versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue32160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30971] Improve code readability of json.tool
New submission from Daniel Himmelstein: 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. -- components: Library (Lib) messages: 298686 nosy: dhimmel priority: normal pull_requests: 2824 severity: normal status: open title: Improve code readability of json.tool versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue30971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27413] Add an option to json.tool to bypass non-ASCII characters.
Changes by Daniel Himmelstein : -- pull_requests: +2779 ___ Python tracker <http://bugs.python.org/issue27413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29636] Specifying indent in the json.tool command
Changes by Daniel Himmelstein : -- pull_requests: +2778 ___ Python tracker <http://bugs.python.org/issue29636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29636] Specifying indent in the json.tool command
Daniel Himmelstein added the comment: @bob.ippolito thanks for pointing to jq as a reference implementation. I updated the pull request (https://git.io/vS9o8) to implement all of the relevant options. Currently, the PR supports the following mutually exclusive arguments: --indent --no-indent --tab --compact These additions took 16 new lines of code in tool.py and 41 new lines of tests. However, I am happy to refactor the tests to be less repetitive if we choose to go forward with these changes. @serhiy.storchaka I took a maximalist approach with respect to adding indentation options to GH #345. Although I know not all of the options may get merged, I thought we might as well work backwards. However, the more I think about it, I do think every option above is a unique and valuable addition. I think that even with the changes, json.tool remains a lightweight wrapper json.load + json.dump. -- ___ Python tracker <http://bugs.python.org/issue29636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29636] Specifying indent in the json.tool command
Daniel Himmelstein added the comment: @serhiy.storchaka I totally understand the desire to keep json.tool simple. However, given the description of json.tool in the documentation (below), I think an indentation option is within scope: > The json.tool module provides a simple command line interface to validate and > pretty-print JSON objects. Indentation/newlines are a fundamental aspect of "pretty-printing". Right now I rarely use json.tool, since indent=4 is too extreme from a visual and file size perspective. Instead I prefer `indent=2` (or even `indent=1`) and I now have to: 1. create a python script to set my desired input 2. make sure every environment has access to this python script (the real annoyance) Currently, json.tool has a --sort-keys argument, which I think is great. --sort-keys is also an essential feature from my perspective (bpo-21650). So in short, I think json.tool is close to being a really useful utility but falls a bit short without an indentation option. Given that json.tool exists, I think it makes sense to take steps to make sure it's actually relevant as a json reformatter. Given this motivation, I'm not opposed to adding --compact, if we're confident it will be forward compatible with the json.dump API. -- ___ Python tracker <http://bugs.python.org/issue29636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29636] Specifying indent in the json.tool command
Daniel Himmelstein added the comment:
To recap the discussion from https://git.io/vyCY8: there are three potential
mutually exclusive command line options that have been suggested. There are as
follows.
```python
import json
obj = [1, 2]
print('--indent=4')
print(json.dumps(obj, indent=4))
print('--no-indent')
print(json.dumps(obj, indent=None))
print('--compact')
print(json.dumps(obj, separators=(',', ':')))
```
which produces the following output:
```
--indent=4
[
1,
2
]
--no-indent
[1, 2]
--compact
[1,2]
```
Currently, https://github.com/python/cpython/pull/345 has implemented --indent
and --no-indent. One suggestion was to replace --no-indent with --compact, but
that would prevent json.tool from outputting YAML < 1.2 compatible JSON.
Therefore, the main question is whether to add --compact or not?
There is a clear use case for --compact. However, it requires a bit more
"logic" as there is no `compact` argument in json.dump. Therefore
@serhiy.storchaka suggests not adding --compact to keep json.tool lightweight.
I disagree that json.tool is "mainly for debugging". I encounter lot's of
applications were JSON needs to be reformatted, so I see json.tool as a
cross-platform command line utility.
However, I am more concerned that the JSON API may change, especially with
respect to the compact encoding (see http://bugs.python.org/issue29540).
Therefore, it seems prudent to let the API evolve and later revisit whether a
--compact argument makes sense.
The danger of adding --compact now would be if json.dump adopts an argument for
--compact that is not compact. Then aligning the json.tool and json.dump
terminology could require backwards incompatible changes.
--
___
Python tracker
<http://bugs.python.org/issue29636>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29636] Specifying indent in the json.tool command
Daniel Himmelstein added the comment: For discussion on how to implement this, see + https://github.com/python/cpython/pull/201#discussion_r102146742 + https://github.com/python/cpython/pull/201#discussion_r102840190 + https://github.com/python/cpython/pull/201#discussion_r102891428 Implementation now moved to https://github.com/python/cpython/issues/345 -- ___ Python tracker <http://bugs.python.org/issue29636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29636] Specifying indent in the json.tool command
Changes by Daniel Himmelstein : -- pull_requests: -230 ___ Python tracker <http://bugs.python.org/issue29636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29636] Specifying indent in the json.tool command
Changes by Daniel Himmelstein : -- pull_requests: +298 ___ Python tracker <http://bugs.python.org/issue29636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27413] Add an option to json.tool to bypass non-ASCII characters.
Changes by Daniel Himmelstein : -- pull_requests: +232 ___ Python tracker <http://bugs.python.org/issue27413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29636] Specifying indent in the json.tool command
New submission from Daniel Himmelstein: The utility of `python -m json.tool` would increase if users could specify the indent level. Example use case: newlines in a JSON document are important for readability and the ability to open in a text editor. However, if the file is large, you can save space by decreasing the indent level. I added an --indent argument to json.tool in https://github.com/python/cpython/pull/201. However, design discussion is required since indent can take an int, string, or None. In addition, a indent string is a tab, which is difficult to pass via a command line argument. Currently, I added the following function to convert the indent option to the indent parameter of json.dump: ``` def parse_indent(indent): """Parse the argparse indent argument.""" if indent == 'None': return None if indent == r'\t': return '\t' try: return int(indent) except ValueError: return indent ``` @inada.naoki mentioned the special casing is undesirable. I agree, but can't think of an alternative. Advice appreciated. -- components: IO messages: 288479 nosy: dhimmel, inada.naoki priority: normal pull_requests: 230 severity: normal status: open title: Specifying indent in the json.tool command type: enhancement versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue29636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
