I'm yet to ever use black. I do see it used a lot though in OSS. Typically at work we've only ever been in fairly small teams so it's easy to get everyone to follow the same kind of structure.

I can see the benefit of it on projects like this though. Even if it might completely destroy my preferred coding styles 😆

We could also put black and flake8 into pre-commit hooks so that they're being ran as people work rather than just when things hit github actions.

For anyone wanting to explore what this would provide, for django-cms or any other project, I've been looking into hooks lately.

Starting with...https://pre-commit.com/

There's a python package you can install,pip install pre-commit

Then create a file in the root of your project called.pre-commit-config.yaml

To simply run black populate that file with

repos:-   repo: https://github.com/psf/black    rev: 21.9b0    hooks:    -   id: black

However you could run isort, flake8, black and various other helpful tools to keep the code clean & tidy.

I'm currently investigating this pre-commit setup, which as of yet, doesn't run black, but does run other useful tools;

repos:- repo: https://github.com/pre-commit/pre-commit-hooks  rev: v3.2.0  hooks:    - id: check-added-large-files    - id: check-ast    - id: check-case-conflict    - id: check-executables-have-shebangs    - id: check-merge-conflict    - id: debug-statements    - id: end-of-file-fixer    - id: trailing-whitespace- repo: https://github.com/pycqa/isort  rev: 5.8.0  hooks:    - id: isort      name: isort (python)- repo: https://github.com/Lucas-C/pre-commit-hooks-safety  rev: v1.2.2  hooks:    - id: python-safety-dependencies-check- repo: https://gitlab.com/pycqa/flake8  rev: 3.8.4  hooks:    - id: flake8      additional_dependencies: [          "flake8-bugbear",          "flake8-comprehensions",          "flake8-mutable",          "flake8-print",          "flake8-simplify",      ]

My biggest issue with installing code formatters on existing projects is that the entire codebase is changed in one commit and tools such as Blame become useless to track changes and help bugfix. This will also make porting changes to v4 more difficult so of course I will complain. :-) Haha.

I see a place for tools like this on new projects. If there was a way to force new changes to respect the rules that would help as it is implemented on each change and won't affect the code change history.

Alright, I've just tried to take a look at black and understand how you can make it work for a project... but you can't. It seems you cannot configure it beyond some basics like line length.

Giving it a run on django-bleach to see how it's code looks and I've gone off it already.

It's ruined the consistency of my code.

I'd rather we didn't use this package and instead just had flake8 running how we want as that will keep code formatted well, while allowing a little freedom.

@marksweb made an interesting point today in the TC meeting:

Would be worth mentioning my pre-commit PR. If people are happy with what I've included, we can spread this to the other repos;django-cms/djangocms-bootstrap4#142

I really like the idea of running eitherblack orblue. The drawback of having it kinda of messing with the git history is really a pain, but I think that we can overcome this problem by setting up it to be run in someparts of the code, like piece by piece instead of the whole project at once. This way we can iterate over it in a better way. There's also someways where we can integrate it in our CI process (however it will need some more work to be done. Just would love to hear what other folks think about it.

As mentioned in our Friday meetings, I disagree with some settings used inblack.

Now that the Django project usesblack, they reduced the maximum line length from 119 to 88. This in my opinion
decreases the readability of code, because either logical lines have to be split or variable names will be shortened.
Most of us developers have wide screens and can fit 119 characters without having to scroll horizontally.

Something else, but less important is quoting. Since Python does not distinguish between single and double
quotes, I use them to distinguish strings semantically. Strings intended to be read by humans are quoted as"…",
while strings intended to be used by the app (keys, etc.), are quoted as'…'.

I fully agree that some parts of the code shall be reformatted, for instance the way we declare models and forms.

Just found out that conversation and thinking about raising a new discussion to useruff instead