I've read the justification for using 88 chars as the default max-line-length in Black:
This number was found to produce significantly shorter files than sticking with 80 (the most popular), or even 79 (used by the standard library). In general, 90-ish seems like the wise choice. If you're paid by the line of code you write, you can pass --line-length with a lower number.
I'd like to suggest that this argument isn't strong enough to justify deviating from a strong standard that exists in the Python community and beyond. Not only does PEP8, and therefore Flake8 and almost every existing Python project use 79 chars, but this is also the default in Prettier and is the basis for the 72-character limit in Git commits. (And, conversely to the sarcastic addendum above - who cares if a file is a few lines longer in this day and age?)
I proposed to Canonical's webteam that we follow Black's standard of 88 chars, but our developers rejected the suggestion primarily based on that it's harder to view in their terminals - which is the reason for the 79 char limit in the first place. And so that we don't need to reconfigure all our Flake8-based CI for our projects immediately to be able to start using Black.
Since Black is meant to use sensible defaults and in most cases remain unconfigured, it seems a real shame that it deviates from PEP8 in just this one case, which will almost inevitably lead to a good number of projects that use it having just one config override for --line-length=79 (as we're planning to do).
This is, of course, just my (or rather, our) 2 cents. Please feel free to make whatever choice you feel is right for the project.
I agree with the @nottrobin.
I'm only using Black on some personal projects, and am using the default line length since I'm not _that_ opinionated. However, I would _prefer_ it to default to a 79-char limit, as that's the standard in much of the Python world, including the standard library itself.
That said, I can see the argument for bucking the trend鈥攁fter all, should we blindly stick to tradition forever? It just seems that most Python code I encounter is either limited to 79 characters per line or not formatted at all (and not for reasons Black addresses anyway).
Either way, thank you for Black. It solved my personal YAPF config dilemmas once and for all (for now). 馃帀
PS.: You might find White amusing.
Sorry, this is unlikely to happen for the reasons you also found in the readme.
@zsol No worries. Thanks for your contributions! 馃枻
Most helpful comment
I agree with the @nottrobin.
I'm only using Black on some personal projects, and am using the default line length since I'm not _that_ opinionated. However, I would _prefer_ it to default to a 79-char limit, as that's the standard in much of the Python world, including the standard library itself.
That said, I can see the argument for bucking the trend鈥攁fter all, should we blindly stick to tradition forever? It just seems that most Python code I encounter is either limited to 79 characters per line or not formatted at all (and not for reasons Black addresses anyway).
Either way, thank you for Black. It solved my personal YAPF config dilemmas once and for all (for now). 馃帀
PS.: You might find White amusing.