Live data from Hacker News

Black – Uncompromising Python code formatter

github.com

111–120 of 251 posts

Re: Black – Uncompromising Python code formatter

#111
post #90

We recently started using a lot of auto-formatters across our Python/iOS/Android code, as the team has grown (there are 17 people touching code at the company now). I like auto-formatting, because it makes PRs less stressful to commit, and makes review comments more focused on stuff that actually matters. How exactly the code gets formatted is not something I care much about, just that it happens consistently, and I…

Because pre-commit can be tough to google sometimes, depending on your search history, here's the direct link: https://pre-commit.com/

I assumed the poster meant the git concept of pre-commit hooks, which is just a shell script - https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

Re: Black – Uncompromising Python code formatter

#113
post #90

Earlier quoted context omitted.

Because pre-commit can be tough to google sometimes, depending on your search history, here's the direct link: https://pre-commit.com/

I assumed the poster meant the git concept of pre-commit hooks, which is just a shell script - https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

Your parent is correct. Here's our pre-commit config too FWIW:

  more .pre-commit-config.yaml
    repos:
      - repo: https://github.com/pre-commit/pre-commit-hooks
        rev: v2.1.0
        hooks:
          - id: end-of-file-fixer
          - id: check-json
          - id: check-yaml
  - repo: https://github.com/asottile/reorder_python_imports
    rev: v1.3.4
    hooks:
      - id: reorder-python-imports
        args: [--application-directories=gaia]
        language_version: python3
  - repo: https://github.com/ambv/black
    rev: stable
    hooks:
      - id: black
        language_version: python3
  - repo: local
    hooks:
      - id: eslint
        name: eslint
        entry: ./frontend/node_modules/.bin/eslint --fix
        language: node
        language_version: system
        files: \.(js|jsx|ts|tsx)$
  - repo: https://github.com/prettier/prettier
    rev: "1.15.3"
    hooks:
      - id: prettier
        files: \.(yml|yaml|md|json)$
        language_version: system

Re: Black – Uncompromising Python code formatter

#114
post #99

Feature request: Add a flag that allows you to specify which lines to format. I'm an auto-formatting true believer, but I hate doing code reviews where the author has run a formatting tool that introduced diffs all over parts of the file that they didn't actually touch. It makes it really hard to review the actual change, and you have to worry about missing something. With something like ClangFormat's '--lines' flag,…

Sounds like you're using it wrong. The autoformatter is for the whole repo, not for individual contributors. The point is that the whole repo has the same style, so you should only ever get diffs on the lines that were changed or the first time you run the autoformatter on the repo (and then you shouldn't be making manual changes that will be hidden amid the autoformatter noise).

Most larger orgs/projects aren't going to be willing to reformat all the code in their repo in one big bang. Regardless of what promises the tool claims to make, you need to be concerned about behavior changes or breakages, and most projects don't have high enough test coverage to cover everything. Depending on the size of your repo, it might not even be technically possible to make this change all at once. It's also much harder to get organizational buy-in on "let's change all existing code in one swoop" vs. "let's require all new code changes to be formatted using this tool".

As I mentioned above, formatting only the diffs also removes most of the pain of any changes to the formatting tool itself that aren't diff-stable.

Re: Black – Uncompromising Python code formatter

#115
post #37

And in Stack Exchange's "The Workplace", people are complaining that their employees strongly object to Black https://workplace.stackexchange.com/questions/136742/virulen...

You can find someone who’ll complain about anything. You have to evaluate whether they’re actually complaining about something valid or just reacting to change.

In the example cited, notice how insubstantial the complaints are? That’s a dead giveaway for someone who is reacting rather than thinking rationally about the goals and benefits. An important distinction to remember here is that we’re talking about something which is safe, fully automatic, and easily integrated into most editors, so the effort to follow it is a few seconds the first time you set it up.

I’ve generally found three classes of reaction to standardizing formatting, linting, and similar style checks: most people just roll with it, some people work through the initial “this is different!” reaction and realize how much easier consistency makes things (it’s been months since code review wasted time on formatting!), and a much group never get over it. I’ve only seen that a couple of times in a couple of decades and those were people who were net losses overall because this was just a symptom of a larger unwillingness to work well with others. The same guys refused to test their code, committed syntax errors or failed merges, wasted time reporting problems due to incredibly hacked up local build environments, etc. The important thing to remember is that those are a vanishingly small part of the community and I would make policy around them only to the extent of figuring out how to keep them from dragging your project down.

Re: Black – Uncompromising Python code formatter

#116
post #105

Earlier quoted context omitted.

Agree 100%, except for a minor quibble at the end. I've tried a few small projects with pipenv and black recently, and though I love black, I'm still struggling to accept pipenv as good. It's so slow so often, and I can't understand why.

I'm coming from managing virtualenvs with s *ty bash scripts on a complex application, so pipenv got rid of a ton of jank, even though it's slow and has issues resolving certain dependencies. I like it because I can document most maintenance tasks as "pipenv sync && pipenv run X" and they Just Work with exactly the library versions specified for that commit. But definitely look into poetry if you're packaging a libra…

Thanks for the suggestion!

Re: Black – Uncompromising Python code formatter

#117
I like black. As hprotagonist pointed out, everyone has a few things about it they don't like. What I like to do:

    $ black --skip-string-normalization my_python_script.py
    $ git add --patch my_python_script.py
Then I accept or reject all its suggestions (other than the string "normalization" idea which is not our convention) on a case-by-case basis, then `git commit; git reset HEAD --hard`.

Re: Black – Uncompromising Python code formatter

#118

I initially used autopep8 and had set vscode to autoformat region on paste. When I changed to black I started getting error messages about region format not supported everytime I pasted. As I mainly use other languages, with formatters with working region support, I went back to autopep8 so I could leave it format region enabled.

Doesn’t it cache everything that it’s formatted, meaning you could paste + save to achieve the same effect? I had the same annoyance as well but stated doing it this way and never had any complaints.

Re: Black – Uncompromising Python code formatter

#119
post #39

Earlier quoted context omitted.

Are you sending unfortunate examples upstream? It's still beta, so it can be improved somewhat.

No, because I believe this is fundamentally unfixable. It's not a matter of changing this or that behavior, it's a matter of (apparent) formatting inconsistencies being important to convey intention and distinguish more important from less important bits. In the example I mentioned, I may sometimes choose to put a small dictionary initialization into a single line if it's just a detail, or may split it into multiple…

Well sure, but an automatic formatter can still be better or worse. Maybe it won't be as good as hand-crafted formatting, but more bad examples can be avoided.

Re: Black – Uncompromising Python code formatter

#120

DEP 0008 ('Formatting Code with Black') was accepted by the Django board last week. They're going to wait until Black has a stable release before reformatting all the code, as there's at least one thing they don't like about how Black handles things. https://github.com/django/deps/blob/master/accepted/0008-bla... https://groups.google.com/forum/#!topic/django-developers/7G...

Seems like there are two things they want to see fixed:

> Several developers report that, in their experience, Black made code formatting worse and decreased readability. Concrete examples shown in the discussion were short lists, which Black reformats when they fit on a single line, and vertically aligned comments, which Black is unable to preserve. This is being addressed [0] in Black and is expected to be resolved before Black becomes stable.

[0] https://github.com/python/black/pull/826

Post reply on HN