Need to bump isort too? 🧐

isort.exceptions.ProfileDoesNotExist: Specified profile of "black" does not exist. 
Available profiles: black,django,pycharm,google,open_stack,plone,attrs,hug,wemake,appnexus.

Computers! 😄 "Specified profile of "black" does not exist." vs "Available profiles: black,..."

flake8 fails too because of the line length. (May as well add the GHA...)

isort failure is resolved (stably) (by the look of it) after running black and then isort again.

@felixxm as per discussion, you'll add the commit running black here, then we can ask the @django/technical-board to approve, and relevant commits to .git-blame-ignore-revs to finished off.

view_tests.tests.test_debug.DebugViewTests.test_template_exceptions started crashing after reformatting the code with Black, it should not happen 😱 💣

Traceback (most recent call last):
  File "tests/view_tests/tests/test_debug.py", line 287, in test_template_exceptions
    self.assertNotEqual(
AssertionError: -1 == -1 : Failed to find 'raise Exception' in last frame of traceback, instead found: raise Exception("boom")

I fixed it in a separate commit.

@felixxm It looks like the flake8 setting is too strict at 88 chars...

@felixxm It looks like the flake8 setting is too strict at 88 chars...

I'm working on updating these ~2000 lines (will do this in a separate commit). IMO we want to be strict, as we were in the past.

Running once with black --preview will rewrap long strings

Running once with black --preview will rewrap long strings

Unfortunately, it doesn't fix all cases and it introduces other unnecessary changes 😞

I'll continue later... 🛠️

Great work here. 👏️

I think the project template and the app template should also be part of this PR.
Maybe they went unnoticed because the file extension is .py-tpl

• https://github.com/django/django/tree/main/django/conf/app_template
• https://github.com/django/django/tree/main/django/conf/project_template

Great work here. clap

I think the project template and the app template should also be part of this PR. Maybe they went unnoticed because the file extension is .py-tpl

* https://github.com/django/django/tree/main/django/conf/app_template

* https://github.com/django/django/tree/main/django/conf/project_template

We will do this in a follow up PR (see comment) as adding .git-blame-ignore-revs. This PR is already massive and almost impossible to rebase. We still have to wait for the votes of the Technical Board etc.

Hi,

We still have to wait for the votes of the Technical Board etc.

Did I miss a vote? :) As far as I remember there was a good consensus about adopting black so I am not sure we need the technical board to vote on this.

My records show that the technical board voted to accept DEP 8 (https://github.com/django/deps/blob/main/accepted/0008-black.rst) on May 10, 2019, so there should be no further vote required.

I think @felixxm may have been referring to a vote on "running black on generated files"? If so, everyone on the board at the time approved the change: django/deps#68

Did I miss a vote? :)

No, you didn't. It's not ready, I need to review docs and rebased after #15407. I will request a vote of the Technical Board later today.

As far as I remember there was a good consensus about adopting black so I am not sure we need the technical board to vote on this.

According to the current policy and DEP-0010 :

Mergers hold the following prerogatives:

• ...
• Requesting a vote of the technical board regarding any minor change if, in the Merger’s opinion, discussion has failed to reach a consensus.

so I cannot merge without a vote of the Technical Board.

In my eyes, we approved all of this ages ago, but has been over two years and the board has changed since then, so we can totally run a vote again if you want to request it!

Requesting a vote of the technical board regarding any minor change if, in the Merger’s opinion, discussion has failed to reach a consensus.

Yes, I didn't realize that you think discussion hasn't reached consensus. Sorry about that.

so we can totally run a vote again if you want to request it!

I would be careful with this one. I am not afraid that a new vote would change the previous result in this specific case, but we shouldn't vote on the same item again. I see technical board votes as binding unless there is a massive change and as such a new board should not be able to overrule a previous decision. But lets wait to see what Mariusz actually wants to vote on and go from there.

Requesting a vote of the technical board regarding any minor change if, in the Merger’s opinion, discussion has failed to reach a consensus.

Yes, I didn't realize that you think discussion hasn't reached consensus. Sorry about that.

It's not a minor change, it's a major change according to DEP-0010:

"Major Change" means any change to Django's codebase of scope significant enough to require the use of the DEP process.

I would be careful with this one. I am not afraid that a new vote would change the previous result in this specific case, but we shouldn't vote on the same item again.

It's not a vote on DEP-0008, it's a vote on it's implementation. We did the same in #14670.

I added release notes and versionchanged annotation.

@django/technical-board This is a DEP-0008's implementation milestone, so according to DEP-0010 I'd like to inform the Technical Board of an intent to merge it. Please hold a vote 🗳️ Voting will end on February 14th, 2022 📆

This PR is almost impossible to rebase, so we'd like to merge it when all members of the Technical Board have cast their vote without waiting to February 14th, 2022. If any of the members of the board have something against it, please express it when casting your vote.

As a follow up, we will create .git-blame-ignore-revs with the following commits:

• Refs #33476 -- Used vertical hanging indentation for format lists with inline comments.
• Refs #33476 -- Refactored problematic code before reformatting by Black.
• Refs #33476 -- Reformatted code with Black.
• Refs #33476 -- Refactored code to strictly match 88 characters line length.

This is my +1 in my capacity as a current technical board member.

Thank you all so much for the work on this, even if we don't agree on all points.

Also: https://www.youtube.com/watch?v=O4irXQhgMqg

+1 from me on merging. Thanks for working on this!

+1 from me as well 🖤

+1 from me of course

+1 from me! 🖤

One small request - could you run the non-Black'd test suite once against the Black'd code? Even just locally with SQLite. I know Black checks for AST equivalence, but there's so much code changing here it's not reviewable, and it's not impossible we'd hit a bug...

One small request - could you run the non-Black'd test suite once against the Black'd code? Even just locally with SQLite. I know Black checks for AST equivalence, but there's so much code changing here it's not reviewable, and it's not impossible we'd hit a bug...

Good point, I get no failures when running on sqlite:

Ran 15566 tests in 154.141s

OK (skipped=1152, expected failures=5)

Thanks y'all 🥇

Double quotes look terrible, try https://github.com/odwyersoftware/brunette for single quotes.

@richardARPANET You won't make many internet friends by making silly drive-by comments like that.

nice bomba patch 💣

@richardARPANET You won't make many internet friends by making silly drive-by comments like that.

Hmm, can I ask why is that silly(excluding the library that they recommended)?

I might be wrong but I remember reading something within the lines that Black maintainer said he wished/preferred to enforce single quotes.

The discussion for reformatting Django with Black was had literally years ago, and then voted on again in this PR. Popping in after the fact to espouse an opinion isn't useful for anyone.

The discussion for reformatting Django with Black was had literally years ago, and then voted on again in this PR. Popping in after the fact to espouse an opinion isn't useful for anyone.

Fair enough, another suggestion is to add skip-string-normalization=true to the black config, which would make this PR way easier for reviewing.

We agreed in DEP-0008 to use Black's default settings, that is, 88 characters per line and double quotes.

Locking discussions in this PR.