I guess we should have some sort of policy about reflow PRs. I'm not looking forward to 100s of those (or a few giant ones).

For now, let's not do any reflow at all. Only new / changed code should use the increased line length.

IMHO many small reflow PRs do not make sense. We can later decide whether we want to do one large one, possibly related to the decision whether we want to use black style.

I'd say that the policy is:

1. Do not reflow just for the sake of it.
2. If one reflows a (large) doc-string when editing it, split it into two commits:
   1. The actual change
   2. The reflow

(For code I expect that there will be fewer changes in practice.)

Sorry I missed the call, but can one briefly remind what arguments were put forward in favor of this change?
I guess I'm relatively indifferent to switching to 88 (staying small enough to make side-by-side diffs is indeed important, but 88 is OK), but would not want to see this as a stepping stone towards moving to black style.

In particular I find black's argument (https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#line-length)

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. Black will try to respect that.

quite dishonest, given that black tends to produce many, many lines with just punctuation (e.g. closing parentheses and brackets), so if you care about file length you should just not put trailing punctuation on its own line and you'll save much more than by bumping the line length limit from 79 to 88.

In fact, sometimes in Matplotlib we do put trailing punctuation by itself on a separate line, but the whole point is that it depends on the semantics of the code, and is not something we do all the time.

I must stress that although I sometimes use black in projects (because other people encourage it or are really bad at manual formatting), I do tend to be quite appalled quite a lot of the time, so I also hope that this change is not a step in that direction.

(I hope/guess that the argument is that doc-strings can sometimes be quite narrow if they show up on a high tab-level. Also, many nested tab-levels combined with long variable names sometimes make it hard to avoid doing ... = (\n. But did't attend either.)

While I have an ambivalent opinion on black, the line length choice seems reasonable.

Maybe black's explanation is a bit sloppy. IMHO less number of lines (=more content on the screen) is only the secondary reason for longer lines. The greater benefit of less wrapping is more "one line = one statement", which increases readability - as long as the lines are not too long.

I also have the feeling that 79 is a bit too tight. If black has found out that 88 chars produce significant less wrapping, that's a valuable result, irrespective of their other style decisions. Unless we have good reasons for a different line length, I think 88 is a good number.

On the call, there was no question of actually starting to use black, just that it was reasonable to choose a line length consistent with their default. The original proposal was a line length of 115. Definitely, any discussion about switching to black would be very broad.

You can also increase it, but remember that people with sight disabilities find it harder to work with line lengths exceeding 100 characters. It also adversely affects side-by-side diff review on typical screen resolutions. Long lines also make it harder to present code neatly in documentation or talk slides.

This was the part of the black documentation I was trying to reference.

(I can just note that assembly rarely has the issue of line length...)

Is this ready to review now that 3.7 is branched? There seems to be some sort of common understanding in the discussions here as well:

• Slightly longer lines are good
• Black is not always good and not the goal

Only question is if we should document any policy about reflowing? I may doubt that the average contributor may not note this. There are currently some (parts of) files which could be reflowed and I have not seen any such PRs during my year involved so I do not really think that we should expect that many now. If we do, we can add a policy?

I would have thought that the vast majority of contributors have no more interest in writing a reflow PR than we have in reviewing one. For any that do, I think it would be reasonable to respond along the lines of “the benefits of this change do not outweigh the effort of reviewing it or the risk of unintended functional changes”, without needing to point to a specific written policy.

The PR guidelines currently state that we conform to PEP8, so possibly that text should be tweaked.

The outstanding tasks are:

• add note that we modify pep8 to increase the line length
• add note in the PR review guide that reflowing should only be done as part of other non-stylistic work
• add text to justify the change someplace in the release notes

I have added notes for each of the highlighted outstanding tasks.

I did not touch MEP8, which is the other place we discuss Matplotlib style outside of release notes as it is my understanding that the MEPs are largely not being used/updated anymore.

@meeseeksdev backport to v3.7.0

Something went wrong ... Please have a look at my logs.

It seems that the branch you are trying to backport to does not exist.

@meeseeksdev backport to v3.7.x