DRAFT: Format python for python36 #1085
Conversation
pip install black black --target-version py36 . Black is the uncompromising Python code formatter. By using it, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters. Blackened code looks the same regardless of the project you're reading. Formatting becomes transparent after a while and you can focus on the content instead. Black makes code review faster by producing the smallest diffs possible. https://github.com/python/black
```bash pip install pyupgrade pyupgrade --py36-plus *.py ```
|
This is mostly changing single-quote to double-quote. Harmless, but also pointless. This also removes python2 support, which I assume is the reason for the AppVeyor failure. Instead of changing this, we might be better off with a better test-framework and test-runners. We need to be able to run slightly different tests with different JSON Readers/Writers and configuration. (See other Issue.) |
|
@cdunn2001 I thought that the intent was to remove python 2 support since it is at end of life. PR #1084 mandates the use of python3 as discussed in #1081. If we want to continue supporting python 2.7, more work will need to be done to PR#1084. |
The point is to provide consistency by following a set of common formatting guides. Black is one of may tools that can do this automatically. My experience in other projects is that "giving control to an automated tool" for formatting greatly increased overall productivity, at the expense of a few "pointless" formatting compromises. That's my 2cents worth of opinion. This was 2 minutes of work, so I'm perfectly happy with a rejection of this PR. |
|
I don't have a problem with dropping python2 support. But AppVeyor does need to pass. As for running "black", I'm fine with it, but I think maybe we should hold off until we finish some serious refactoring or copy/pasting to ensure that we run separate tests for the old and new Readers. Git-history can be helpful for tracking the provenance of bugs, and a change this large muddies the history. But after we're stable, I'd be in favor of this PR. (And I'm not strongly opposed today.) |
|
@cdunn2001 Thanks. Let's revisit this after some stability isssues are resolved. It really is 2-3 minutes of work to remake this PR. |
hjmjohnson
changed the title
|
I'm going to close this out as stale. Feel free to revisit this and reopen as appropriate. |
No description provided.