Inconsistent max-line behavior between black and flake8-bugbear with B950 rule

[sergeant-wizard]

# 000000001111111111222222222233333333334444444444555555555566666666667777777777888888888
# 23465789012345678901234567890123456789012345678901234567890123456789012345678901234567
variable = "black tries to format lines exceeding 88 lines, but doesn't break long strings like this into smaller lines and gives up"

Since the current behavior selects B950 explicitly, pysen will report a violation of B950 for the above code.
However, pysen run format will do nothing to format the above code since black doesn't know where to break line.
Therefore, users will see a B950 violation even though black will do nothing to rectify the violation.

Some users have reported this to be an unexpected behavior since they have to edit their code manually to get rid of the lint violation.
In most cases black will format lines to be smaller than 88 lines anyways, which is causing a redundant check from flake8 and black, where ONLY flake8 complains in this particular case.

I want to bring removing the B950 select option option to the table. This will be a breaking change.

Here's what we should expect upon removing B950:

• If the user doesn't use bugbear: nothing changes (they'll have a diff in setup.cfg)
• If the user uses bugbear
  • If the user doesn't have long lines in his/her code: nothing changes (redundant check will be resolved)
  • If the user does have long lines in his/her code: The user will no longer have to edit the line manually to resolve the violation. HOWEVER, users that actually wanted to enforce this manual editing will no longer have this behavior from pysen.

[Hakuyume]

I think we should keep the current behavior.

• black does not check the line-width. It only tries shorten lines.
• Even if black fails to shorten, the line still violates the line-width.