Assert support for Black formatted code
dunk opened this issue · 4 comments
Black is the new orange... is the new black. Or something. In either case it seems to have become inexplicably popular despite being essentially about incarceration. Would it be possible for flake8-aaa to support the new dictator in town?
To me it looks like Black is a tool for someone who cannot format properly himself and flake8-aaa is a tool for learning and validating that you have formatted your code correctly. I don't see how flake8-aaa would be improved by using Black.
On a side note: Black seems to decrease the readability from what I have found playing around with it. I pretty much don't see the point why a program should format my code, while I can do it better.
@dunk Thanks for opening this issue 👍
Black is the new orange
Yes - at a recent Python meetup about 90% of the developers were using Black on their projects. Compared with 5% using Yapf (only me). In addition, as shared with me by @adamchainz, Django recently accepted this proposal: https://github.com/django/deps/blob/master/accepted/0008-black.rst so that:
All Python code in Django is formatted with Black, using its default settings, that is, 88 characters per line and double quotes.
Would it be possible for flake8-aaa to support the new dictator in town?
First, just to clarify "support" - for me I would take support to mean "accept tests written with the AAA pattern and formatted with Black". If that's the case, then yes - if it turns out that the general AAA pattern that I've been following is compatible with Black 🤞 , then it should be supported here (no linting would fail with AAA errors).
I think that Flake8-aaa should be tested against a bunch of "good" tests copied from /examples/good and formatted with Black using default settings. If they all pass, then that'll be good new - I'll experiment with that now...
@daknuett Thanks for the comments 👍
flake8-aaa is a tool for learning and validating that you have formatted your code correctly
Yes! Learning and validating!
My hope is that we can find a balance for Flake8-aaa so that it can maintain both roles:
-
As a learning tool - giving helpful feedback when linting fails. This will probably happen most when invoked via the command line and hopefully with some of the helpful output as we've discussed on #62
-
As an assistant gatekeeper on projects - raising errors when tests appear poorly structured or overly complex (validating). In this respect, many open source projects are using linters and formatters like Flake8, Black, yapf, isort, etc to maintain the quality of their codebase. To function in this layer, it's important that Flake8-aaa does not conflict with how popular Python formatters are laying out the code. I say "assistant gatekeeper" because Flake8-aaa would need to plug in to Flake8 which should be on a project's existing test suite.
I don't see how flake8-aaa would be improved by using Black.
This issue is not asking for Flake8-aaa to use Black to format its codebase (I hope - correct me if I'm wrong @dunk). Instead - as mentioned - I think the intention is to assert that Black's formatting and Flake8-aaa's checking do not conflict.
I hope that's right and true!
Neato!