Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradual adoption: option to only format PEP8 errors #134

Closed
max-sixty opened this issue Apr 16, 2018 · 7 comments
Closed

Gradual adoption: option to only format PEP8 errors #134

max-sixty opened this issue Apr 16, 2018 · 7 comments
Labels
R: rejected This will not be worked on T: style What do we want Blackened code to look like?

Comments

@max-sixty
Copy link

If I were starting a project from scratch, I'd start with enforcing black. But most code is written on existing projects, and converting everything to black requires a high degree of confidence and share of agreement within contributors.

What do you think about enabling an option in black to reformat only:

  • Code that violates PEP8 / some rules
  • Code that has been changed

One of the nice attributes of autopep8 is that it only changes code where there's a problem. This has two big advantages to adoption:

  • The impact is limited to strict, unambiguous improvements
  • Projects don't require everyone to agree that autopep8 is the correct tool - an individual / subset can start using it for their contributions

Thanks again for the project

@ambv
Copy link
Collaborator

ambv commented Apr 16, 2018

Black by design doesn't enable reformatting parts of the file. This functionality is against PEP 8 which states that internal consistency within the file is more important than any particular style. If you used Black for this purpose and somebody else kept using autopep8 or YAPF, your styles would fight with each other.

Black is both a tool and a code style. You are adopting the style. The tool is merely an automated way of enforcing it. Yes, this requires agreement within your project that this is the style your team wants to enforce. If you decide that you don't like the particular style and you'd rather keep formatting by hand instead, that's fine by me. If you decide that the style is fine but the tool is not stable enough yet, hopefully this will be gradually resolved by increased adoption of the tool and squashing bugs one by one.

As far as responding to particular pycodestyle violations and only formatting that code, I fully agree with YAPF's take on it which is that this is a suboptimal strategy. It also famously leads to situations where one fix may introduce other pycodestyle violations.

Summing up, this is deliberately not in scope for this project.

@ambv ambv closed this as completed Apr 16, 2018
@ambv ambv added R: rejected This will not be worked on T: style What do we want Blackened code to look like? labels Apr 16, 2018
@max-sixty
Copy link
Author

OK, thanks for the full response!

@wbolster
Copy link
Contributor

wbolster commented Feb 6, 2019

fyi, i wrote https://github.com/wbolster/black-macchiato

@DylanYoung
Copy link

DylanYoung commented Feb 11, 2020

I don't think that's how time works.... It's continuous, not discrete ;)

@akaihola
Copy link

The darker tool applies Black formatting only to lines which have changed in the Git working tree since the last commit.

@pauloneves
Copy link

Sure the formatting consistency in the file is important and black shouldn't fight with other formatters. My use case is different. My coworkers didn't use any formatter. I persuaded the team to use black as standard formatter, but we have a lot of already written code.

When I'm fixing a bug or adding a feature, I'd like to use black in the new code. I can't reformat all the file because it would display my name when someone uses the git blame command. Who edited a line of code is a very important info for developing software. Without partial formatting, black is useless for already existing code base.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
R: rejected This will not be worked on T: style What do we want Blackened code to look like?
Projects
None yet
Development

No branches or pull requests

7 participants