Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to black #1039

Merged
merged 33 commits into from
Jun 1, 2021
Merged

Migrate to black #1039

merged 33 commits into from
Jun 1, 2021

Conversation

neiljp
Copy link
Collaborator

@neiljp neiljp commented May 27, 2021

This PR comprises:

  • many prep commits motivated by - though not all required for - a better post-black experience.
  • black configuration in pyproject.toml
  • removal of a conflicting flake8 rule
  • addition of black linting to tools/lint-all (so make check and make lint) and fixing to make fix
  • two commits for migrating structure only, then adjusting to a standard quote style
  • enforcement of black linting via CI

This makes tests easier to read and more compact.
(it will also avoid issues with long lines with `black` later)

NOTE: The code/test complexity suggests we may want to refactor later.
@zulipbot zulipbot added the size: XL [Automatic label added by zulipbot] label May 27, 2021
@@ -17,6 +17,7 @@


CONTROLLER = 'zulipterminal.core.Controller'
MODEL = 'zulipterminal.model.Model'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just wanted to point that I had a PR #959 that does a general simplification of patches in all tests. Let me know if I should make it review-ready if we wish to merge it first.

EDIT: I just updated that PR after rebasing and resolving conflicts.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ezio-Sarthak Thanks for reminding me of your PR 👍

I welcome your intent to add more constants to improve readability; the main challenge with using these is that we don't currently have much of a "standard" way of applying these constants - or it seems that way, but isn't quite. In some pre-existing cases we have files referred to, others to classes, and I think this is where we would benefit from standardizing and clarying. You'll note that in my commit I only extracted the classes, since they were both the longest - so more likely to benefit from compacting the long lines - but also that it made clear that others were module-specific, either imports or not in the main class.

@neiljp neiljp force-pushed the 2021-05-26-black-hoisted branch 2 times, most recently from bdfe608 to cd017ed Compare May 30, 2021 15:19
Copy link
Member

@preetmishra preetmishra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@neiljp Thanks for putting all the work into this! This looks great. 👍

neiljp added 20 commits May 30, 2021 15:27
The recent increased maximum line-length allows these to be combined,
which improves readability and reduced visual noise.

These were originally introduced due to breaking across lines, which is
still required in some cases.
This is similar to the previous commit, but also involves minimal indent
adjustment to pass linting.
(the minimal indenting will be adjusted automatically later upon
application of black)

The parametrize names being split into lists was originally introduced
due to breaking across lines, which is still required in some cases.
This is possible now due to the longer maximum line-length.
(`black` cannot perform this reorganizing automatically)
Increased maximum longer line-length allows these to be removed.
(black won't remove these automatically later)
Trailing commas have meaning to `black` and force multi-line formatting where not
necessary.
This makes it clearer which test case has which id, compared to having
separate lists of test case values and ids, particularly when such lists
are long.
(this will potentially be of more importance when `black` is in use,
 when it can expand case values over many lines)
`case` prefixes added, in preparation for addition of inline ids.

Two entries separated onto different lines.

Other reformatting to satisfy flake8.
This will be particularly useful with `black` in use, but also clarifies
which id matches which test case.
This is a precursor reformat to adding inline test ids.
Once we apply `black`, this will be reformatted; this commit moves the
comment so it stays in a reasonable position.
Upon application of `black`, subsequent lines are not obviously grouped
together without these.
Upon application of `black`, these test cases become vertical; adding
these commas ensures the ids are also vertical rather than combining on
one line.
The structure indicates the pattern of covered values, which is not
evident in a single list.
These implicitly-combined multiline strings are visually clear as
currently laid out; line combination as applied by `black` makes this
less clear.
These can force multi-line formatting where not necessary in black.
These will force multi-line formatting when black is applied.
With the longer maximum line-length, this allows simplification of
strings spanning multiple lines which are implicitly combined. Applying
`black` will soon tidy this further, but does not merge adjacent
implicitly joinable strings; this commit handles this manually to avoid
such strings being placed manually on the same lines, or split
awkwardly.
With the longer maximum line-length some of these can be simpler. More
importantly `black` will not always automatically remove these, leading
to extra indenting and lines for parentheses in some cases.
These comments would be misplaced after applying `black`, so this commit
manually adjust the formatting so that the comments are maintained,
including one mypy type-ignore.
@neiljp neiljp changed the title WIP: Migrate to black Migrate to black May 31, 2021
@neiljp neiljp merged commit f79359f into zulip:main Jun 1, 2021
@neiljp neiljp added this to the Next Release milestone Jun 1, 2021
@neiljp
Copy link
Collaborator Author

neiljp commented Jun 1, 2021

Thanks for all the feedback everyone - this has been rather a lot of effort but I'm looking forward to it being useful in future! 🎉

@neiljp neiljp added the area: infrastructure Project infrastructure label Feb 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: infrastructure Project infrastructure size: XL [Automatic label added by zulipbot]
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants