I don't feel very strongly against or in support of this. I personally love black, but the only rationale I can think of excluding migrations is that it increases the migration file sizes a lot in attempt to make it more readable, and I am not sure that's necessary. I feel the number of migrations can become a lot, and with bigger file sizes, that don't need to be very readable, this may take more time in things like git cloning, etc.? Though maybe realistically not so much, hence I don't have a strong personal opinion against this PR.

I wouldn't format migration files. They rarely need reading and when they do, the long lines tend to be beneficial because you can [more] easily see all the field names in a model without the distraction of the attributes, for example.

@SaptakS I checked the before-and-after total file sizes. The difference is 12 KB. For comparison, foundation/migrations/0005_alter_approvedgrant_amount_currency_and_more.py file is 20 KB. The difference can easily be compensated for by squashing a single migration. Also, git is extremely scalable, and it can handle repositories with multiple hundreds of GBs in size (We are at 33 MB)

As an additional data point, this is GrandPerspective output for the project folder:

A single file in the .git folder is ~2000x bigger than the size difference created by the formatting.

@marksweb Thanks for the input. I don't personally disagree with your points, but I also don't strongly agree with them. Both points you mentioned are subjective, and the second one depends on personal taste, your IDE config, etc. As a tool, black's philosophy is

Black is the uncompromising Python code formatter. By using it, you agree to cede control over minutiae of hand-formatting. In return, black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.

That approach aims to remove the need for this type of "how do we format things" questions and apply a consistent styling without requiring one to think about which rules to use or where to apply them. And again, Django's default is to format the generated files. For the sake of compliance with both tools' approaches and to avoid falling into the trap of bikeshedding, I think it's better to proceed with a minimal amount of customization.

Django's default is to format the generated files.

This point does make me more inclined to accepting this PR.