I've been using Black's default line length of 88 characters since I started using Black a few years ago. I quite like their rationale for this number:

You probably noticed the peculiar default line length. Black defaults to 88 characters per line, which happens to be 10% over 80. 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. However, sometimes it won’t be able to without breaking other rules. In those rare cases, auto-formatted code will exceed your allotted limit.

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.

Source: https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html

I do not have strong feelings about this. I would be reluctant to introduce any new rule that leaves a lot of our existing code non-compliant, but that's only a danger if we decide on a line-length that's shorted than the standard in existing repos.

I personally like the 80-character limit, it's true that screens are now much larger than they used to be, but I find shorter lines much easier to read, and I really like being able to open two files side-by-side. On my 16-inch laptop at my current font size I can fit about 200 columns, and on my previous smaller laptop I could fit about 170, so I find that 80 is still a reasonable setting even on modern computers, if you frequently open two files side-by-side.

So my personal preference is to keep the limit at 80, but I'm also happy to increase it to 88 or 100 if other people find it useful.

I don't have strong opinions and don't have the interest/energy to argue about this very much, but:

• I don't want to think about this when writing code, and instead want a formatter that does it automatically for me (black does this currently and I think this is not about changing that, correct?)
• If I had to choose some value, I'd go with 88 or 100. 80 is a bit too short and it forces splitting many lines that I'd personally not split, and longer lines are hard to use when having two files or terminal windows open at the same time.

The only strong opinion I have on this would be to utilize a code formatter, and very strongly consider the default settings. I used to be annoyed by oddly split lines just over the limit and for autoformatting to change my logically laid out code; but in the end consistently formatted code was more useful than my attempts at curation. My time was better spent writing code and not formatting.

The truth is that the WMF has organically standarized on tox + black for auto formatting. I don't think that part is controversial. Or at least, is not my intention that we discuss it in this ticket.

In T327087#8535654, @aborrero wrote:

The truth is that the WMF has organically standarized on tox + black for auto formatting. I don't think that part is controversial. Or at least, is not my intention that we discuss it in this ticket.

This team explicitly standardized on black and 80 char line lengths in the past as documented on https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/Python_coding. We did that prior to any other WMF teams to my knowledge.

The 80 characters per line is something that was introduced decades ago when screens were small.
Nowadays, virtually nobody codes or reads code on a setup such as:

can't fit more than 80 characters
can't zoom or scroll horizontally to overcome such limitation

I guess that I should be ashamed to say that I deliberately choose to develop software using an 80-character wide text terminal and vim with the framing given for this change. Rather than using ageist language to belittle me, could someone please actually make a reasoned argument for longer line lengths.

The only strong opinion I have in this subject, is to make sure that whichever configuration is chosen, it's setup in a way that running the tools by themselves (ex. black/isort/... whatever tools we use) pick up the configuration without the need of extra tweaks.

Then as a datapoint, my setup allows me to comfortably work with 2 ~125 column files, side-by-side, as I use a big screen most of the time. I avoid using my laptop regularly as the screen is too small anyhow (I end up trying to play with zooms/resolutions and never get a comfortable setup), so I can go by with whatever option is decided.

Said that, I weakly vote for 100, but would not be disturbed by using any other line length.

Note again that this has to go paired with setting up the config in a place that the tooling will find by default and without wrappers (that allows me to easily set it up on any editor).

In T327087#8545029, @bd808 wrote:

I guess that I should be ashamed to say that I deliberately choose to develop software using an 80-character wide text terminal and vim with the framing given for this change. Rather than using ageist language to belittle me, could someone please actually make a reasoned argument for longer line lengths.

You ask for reasoned arguments to counter a deliberate choice of yours. A choice that doesn't seem reasoned either.
I don't think that kind of debate would be a good use of our time. I'm sorry you felt discriminated, that wasn't my intention.

I will, however, document a few divergences from the established default of 80:

• tool disable-tool (using 120)
• tools-webservice (disabling flake8 E501 to use black's default)
• jobs framework (using 100 and using 100)
• toolforge grid-webservices (using 100) -- what's this even?
• openstack_puppetenc (using 100)

(...I got bored and stopped searching)

I interpret the divergences as fatigue from the 80 limit.

In T327087#8569222, @aborrero wrote:

In T327087#8545029, @bd808 wrote:

I guess that I should be ashamed to say that I deliberately choose to develop software using an 80-character wide text terminal and vim with the framing given for this change. Rather than using ageist language to belittle me, could someone please actually make a reasoned argument for longer line lengths.

You ask for reasoned arguments to counter a deliberate choice of yours. A choice that doesn't seem reasoned either.

https://peps.python.org/pep-0008/#maximum-line-length has a number of reasons, the strongest of which may be "The default wrapping in most tools disrupts the visual structure of the code, making it more difficult to understand. The limits are chosen to avoid wrapping in editors with the window width set to 80, even if the tool places a marker glyph in the final column when wrapping lines. Some web based tools may not offer dynamic line wrapping at all."

If the question is about the reasons I deliberately choose to work within an 80 column window it is a combination of familiarity and ease of moving from device to device. Nearly every device I have ever used that is capable of ssh is also capable of 80 column output.

I will, however, document a few divergences from the established default of 80:

• tool disable-tool (using 120)

Flake8 here is configured to allow 120 char lines, but black is actually configured for 80 char lines.

• tools-webservice (disabling flake8 E501 to use black's default)

Here black is actually configured for 79 columns.

• jobs framework (using 100 and using 100)

Did you deliberately ignore the prior consensus at https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/Python_coding when you configured these two repos or did we not sufficiently socialize the prior decision?

• toolforge grid-webservices (using 100) -- what's this even?

Some tool that Taavi made which is not bound by any agreements of the Wikimedia Cloud Services team.

• openstack_puppetenc (using 100)

This is more stuff made by Taavi and not by the WMCS team.

(...I got bored and stopped searching)

I interpret the divergences as fatigue from the 80 limit.