This only works locally as GitHub does not support (yet) this functionality. We can mark the commit which applied Black to an exception list `.git-blame-ignore-revs`, see (), so that `git` does not see the commit and does not pollute the output of `git blame`. Document Black use in the developer guides. Remove `pycodestyle` from CI and `tox.ini`. Add isort (still not sure, maybe latter as this could break things with circular dependencies in some places). Make the max line length 88, Black's default. black configuration is in `pyproject.toml` and `flake8` ones in `tox.ini`. Just commit and it fixes the code for you, no questions asked. The goal is to remove any churn on the development side. Add a pre-commit hooks for Black and `flake8`. I will wait for comments before doing more work.** **I am labelling this PR as in need of a decision. It would be the entire responsibility of Black to format code, hence make our code base very consistent and remove the extra load due to styling (both in writing code and reviewing). This … was discussed during the last [community Using Black would remove all discussions about code style in PRs. Use the available horizontal space as much as possible. Single digit, brackets on a line are forbidden. * When splitting an equation, new lines should start with the operator linking the previous and next logical block. Except if : (i) the operator is used to define the sign of the number (ii) the operator is used in a group to mark higher priority. * There a space before and after `-`, `+`. Only exception is if the expression consist of a single operator linking two groups. * There is no space before and after operators `*,/`. * There is no space before and after `**`. * If operators with different priorities are used, add whitespace around the operators with the lowest priority(ies). These rules respect and complement the PEP8 (relevant sections includes ()and ()) To format mathematical expressions, the following rules must be followed. To quickstart things here are some ideas: I think such a document is missing from the scientific community and my hope is that we can all agree on something :smiley: The rules must be coherent, extensive and opinionated (one way to do something, unambiguous wording) so they can be integrated in a tool (that tool may be Black). The goal of this issue is to document and establish a strict set of rules to write maths. To be able to use tools (like, but not limited … to Black), we need to define how we, as the scientific community and not just SciPy, want mathematical equations to be rendered. # pre-commit runs automaticallyĮXACTLY the same linter is run during CI, so if your commit passes you don’t have to wait for the CI to tell you that you’ve made a formatting mistake (I’m looking at you, SciPy!) For those of you who haven’t come across pre-commit before, it integrates very nicely into the development process: That way, you gradually transition the codebase ( may have an opinion on which route works best?)Īre there any major concerns from the developer community about adding black as a linter? One unfortunate side-effect is that black will make many older PRs unmergeable if applied wholesale to the project, but we could also just put it in place to check patches as they roll in. In PR 6563 I’ve added some innocuous linters, but have left black out on purpose until we’ve had time to discuss. BUT I think the benefit of not having to worry about formatting ever again is totally worth it. Now, I know that black is somewhat controversial (because the code it produces isn’t always what we would have written). A very effective way to achieve that is to use a formatter, such as black. I thoroughly enjoy working on projects where we never, ever have to debate style in PRs.
0 Comments
Leave a Reply. |