On Sat, Apr 13, 2019 at 12:07 PM Florian Apolloner <[email protected]> wrote:
> As expressed at Djangocon Europe, I am hugely in favor for adopting black. > A quick glance suggests this would result in ~20k lines changed (~27% of non-whitespace, non-comment code lines) in django/ and ~58k lines changed (~41%) in tests/ (with `--line-length=119`). After the initial pass to fix everything `black -l 119 tests/ django/` takes only 2.3 seconds to run (!), though I'm sure my OS had all the files cached at that point. Without normalizing strings, the number of changed lines comes down to ~14k (~19%) for django/ and ~23k (~16%) for tests/ (with `--skip-string-normalization --line-length=119`). I'm sure some people will see this as "a ton" and others "only that much?" :-) (My line counts are imperfect and approximate, and you'll likely get somewhat different numbers if you try this yourself.) If we choose to do this there are a few things to consider: > > * Line-length, we probably want to stay at 119 I guess > Perhaps we could compromise and choose something in the middle, for the reasons noted in the docs: https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length We should also consider adding max-doc-length for flake8 to our setup.cfg, and/or forego the shorter requirement for comments/docstrings *if* we shorten the maximum line length for code. This section <https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/> in the docs will need updating if we hand this off to a 3rd-party formatter (in particular the sentence, "Don’t limit lines of code to 79 characters if it means the code looks significantly uglier or is harder to read." since we'll no longer have the option of shortening lines to 79 characters arbitrarily). * String normalization, I'd be in favor of following black defaults here, > but I am open to be convinced otherwise > It'd be nice to minimize the diff, but I'd be fine either way. If we're going to do it eventually, better to do so all at once. > * We will need to adjust the isort configuration ( > https://github.com/ambv/black/blob/master/README.md#how-black-wraps-lines > ) > +1 Overall, the main downside I see is the large, fairly useless changeset this would create and the impact it would have, such as reduced utility of `git blame` for some portion of the code for the foreseeable future and interruption to all in-progress PRs. Problems that can be worked around, sure, but it would be an interruption to ongoing work nonetheless. One question: Would we want to update some/all code samples in the docs with the same code style? I imagine that could be a fairly time-intensive endeavor, unless someone's already found a way to automate the process. In particular, Black's format for chaining method calls <https://black.readthedocs.io/en/stable/the_black_code_style.html#call-chains> differs from Django's preferred style <https://docs.djangoproject.com/en/2.2/topics/db/queries/#chaining-filters>. Applying this standard to the docs without discretion may lead to less readable docs, IMO...on the other hand, it's odd to have code samples that don't pass our own tests... In any case, while this sounds like a non-trivial project with some questions to work through yet, I too like not having to worry about code formatting and don't have any real objections to this. Cheers, *Tobias McNulty*Chief Executive Officer [email protected] www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKQo_7aru%3DGJWQGj8g1Fv69iq2H3Wp6%3D0%2Bdp2NKTaHh4OA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
