STY: use black

[jreback]

I have seen a number of other project adopt: https://pypi.org/project/black/, as well as use in my company.

This basically is a style formatter that plays nice with flake8 and is completely opionated, the only option is line-length. This is a good thing.

This would involve a one-time updating of code (though we can do it somewhat incrementally).

[TomAugspurger]

+1. Not having to worry about formatting is nice. We use it for dask-ml and the reception has been positive. Dask is adopting it soon. The tricky part is of course the outstanding PRs. It may be worth doing a mini-sprint to get as many of those resolved (merged or closed) as possible before applying black. For the remainder, perhaps a maintainer could push a commit applying black on the PR and fixing merge conflicts, so that the contributor doesn't need to. I would also recommend pairing this with a pre-commit-config in the repo: #23616

…

On Tue, Jun 18, 2019 at 9:41 AM Jeff Reback ***@***.***> wrote: I have seen a number of other project adopt: https://pypi.org/project/black/, as well as use in my company. This basically is a style formatter that plays nice with flake8 and is completely opionated, the only option is line-length. This is a good thing. This would involve a one-time updating of code (though we can do it somewhat incrementally). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#26926?email_source=notifications&email_token=AAKAOIS4D26NSFOGN4EDS6TP3DX3JA5CNFSM4HZAZSP2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G2FIIAQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKAOISJFFSGEOSKMIMNLODP3DX3JANCNFSM4HZAZSPQ> .

[jorisvandenbossche]

Could we start with requiring it for new code? (assuming black has a reformat-diff-only option)

[simonjayhawkins]

+1 in principle

just tried it with VSCode extension.

can't apply to a selection, not a problem if code is already blackened.

                                raise ValueError('cannot convert float '
                                                 'NaN to integer')

                                raise ValueError(
                                    "cannot convert float " "NaN to integer"
                                )

may want a second pass to tidy things like this.

from pandas.core.dtypes.generic import (
    ABCDataFrame, ABCDateOffset, ABCDatetimeArray, ABCIndexClass,
    ABCMultiIndex, ABCPandasArray, ABCPeriodIndex, ABCSeries,
    ABCTimedeltaArray, ABCTimedeltaIndex)

from pandas.core.dtypes.generic import (
    ABCDataFrame,
    ABCDateOffset,
    ABCDatetimeArray,
    ABCIndexClass,
    ABCMultiIndex,
    ABCPandasArray,
    ABCPeriodIndex,
    ABCSeries,
    ABCTimedeltaArray,
    ABCTimedeltaIndex,
)

may need a test to make sure it plays nice with isort

[TomAugspurger]

With a bit of configuration, it plays fine with isort. Black only supports pyproject.toml for configuration, which we've had to remove for now, but I think it's safe to re-introduce. If we do this, we should revisit the 80-character line length limit. I think now that we're adding type annotations something a bit longer makes sense (maybe black's default of 88).

…

On Tue, Jun 18, 2019 at 2:01 PM Simon Hawkins ***@***.***> wrote: +1 in principle just tried it with VSCode extension. can't apply to a selection, not a problem if code is already blackened. raise ValueError('cannot convert float ' 'NaN to integer') raise ValueError( "cannot convert float " "NaN to integer" ) may want a second pass to tidy things like this. from pandas.core.dtypes.generic import ( ABCDataFrame, ABCDateOffset, ABCDatetimeArray, ABCIndexClass, ABCMultiIndex, ABCPandasArray, ABCPeriodIndex, ABCSeries, ABCTimedeltaArray, ABCTimedeltaIndex) from pandas.core.dtypes.generic import ( ABCDataFrame, ABCDateOffset, ABCDatetimeArray, ABCIndexClass, ABCMultiIndex, ABCPandasArray, ABCPeriodIndex, ABCSeries, ABCTimedeltaArray, ABCTimedeltaIndex, ) may need a test to make sure it plays nice with isort — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#26926?email_source=notifications&email_token=AAKAOIXPAMKTZXYNVFKUWF3P3EWIVA5CNFSM4HZAZSP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX7UKFA#issuecomment-503268628>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKAOIS476VFPZT3JN3R6M3P3EWIVANCNFSM4HZAZSPQ> .

[Batalex]

If it helps in any way, here is an isort config which plays fine with black and pre-commit in my projects

[settings]
multi_line_output=3
include_trailing_comma=True
force_grid_wrap=0
combine_as_imports=True
line_length=88

[jorisvandenbossche]

So we discussed it last week on the call, and no strong objections were raised (and indeed, it does deliberately not support only blackening the diff to do it incrementally).

So we will try to push this during the sprints now.

[vaibhavhrt]

I don't think 80 char limit should be increased. When working with two files side by side, in Editors like VS Code, 80 characters lines fits perfectly. Hence you can work with two files at a time(which is handy like almost all the time) without having to scroll sideways.
Something like this:

The laptop I am on rn is kinda small, so I can't even fit 80 chars properly. But on my other laptop it fits

[simonjayhawkins]

i'd also be happier with not increasing the line length. the standard 79 chars would be good.

for accessibility I prefer to have larger fonts, so regardless of the laptop resolution, the shorter line length helps with side by side files.

[jorisvandenbossche]

I personally like the somewhat longer line length, but certainly understand those arguments to keep it at 79 (I also regularly have files side by side, and it gets more tight in that way).

With the tendency of black to create more horizontal lines, I think it is nice to use their default of 88. And as Tom said above with adding more typing annotations, a longer line length can also help there.

There is one practical problem with changing their default. Black uses a pyproject.toml for config, and once you have such a file, pip will also use it. So that would mean we first need to to finish up #25227.

[simonjayhawkins]

There is one practical problem with changing their default. Black uses a pyproject.toml for config, and once you have such a file, pip will also use it. So that would mean we first need to to finish up #25227.

Although not the recommended approach, would using the pre-commit hook skirt this issue? https://black.readthedocs.io/en/stable/version_control_integration.html#version-control-integration

[jbrockmendel]

Closable?