How long should a line of Python be? PEP 8 says 79 characters. Black says 88. Your colleague with the ultrawide monitor says 120, and the ensuing argument says 45 minutes.
The 79-character limit dates back to terminals that assumed 80 columns, and PEP 8 still opens with “Limit all lines to a maximum of 79 characters,” though it also, less famously, permits teams that agree to go “up to 99 characters.” Black picked 88 in 2018 because it “happens to be 10% over 80” and “was found to produce significantly shorter files” (yeah, the docs really say that). Ruff adopted Black’s 88 as its default, and 100 and 120 have become common for modern screens.
I’ve been working on lots of Python packages recently and realized I’m not even consistent across my own repos. I thought I’d do some searching to find out if there was some standard for newer Python packages. My initial searches came up empty. So I thought, maybe I’ll just look at what people are doing on GitHub. Surely someone must have done this.
Well, they haven’t. But looking for it led me to a 2025 python.org discussion about relaxing PEP 8, where Neil Girdhar suggested something similar: “Comb through the 100 most popular Python projects and inspect their line width.”
I still couldn’t find evidence that anyone had actually done it. So, with the help of Claude, I decided to see what the data say.
The method
I used two complementary approaches, together they give us an idea of what the community is actually doing:
- Top-starred survey: I fetched and parsed the actual config files from 4,847 well-starred GitHub repositories to extract each project’s configured limit. Precise but elitist.
- GitHub-wide code search: Approximate hit counts for exact config phrases (like
"line-length = 100") across every indexed repository on GitHub. Much cruder, but two orders of magnitude more data (~628,000 hits).
Top-starred survey
I took every GitHub repository whose primary language is Python, with roughly 1,450 stars or more, pushed within the last year, excluding forks and archived repos: 4,847 repositories as of August 2026.
For each one, I fetched the eleven files where Python line-length configuration lives (pyproject.toml, setup.cfg, tox.ini, .flake8, ruff.toml, .ruff.toml, .editorconfig, .pylintrc, pylintrc, .pre-commit-config.yaml, .style.yapf) and parsed out the configured limit for Black, Ruff, flake8, pycodestyle, pylint, yapf, autopep8, and EditorConfig, including limits passed as pre-commit hook arguments.
I want the configured maximum line length, what the project chose, not the longest line somebody snuck past review. When multiple tools set a limit, I took the formatter’s (Black, then Ruff), though conflicts barely exist anyway.
About half the sample (2,362 repos) has no line-length configuration at all; that bucket is full of awesome-lists, tutorials, and projects that simply don’t run a formatter or linter. For the other 2,485 repos, a limit can be determined in one of two ways: 1,905 write a number into a config file, while the remaining 580 run a formatter or linter but never set its line length, which commits them to the tool’s default (88 for Black and Ruff, 79 for flake8, 100 for pylint).
GitHub-wide code search
As a cross-check, I also queried GitHub’s code search for approximate hit counts of exact config phrases, searching "line-length = 100" in TOML files and so on, for each candidate value, in three config syntaxes, across every indexed repository on GitHub.
This measurement counts files rather than projects, includes forks, and has no popularity filter.
But at ~628,000 hits it covers the long tail of ordinary projects that the star cutoff excludes.
The result
Here’s what both measurements look like. Blue is the top-starred survey (explicit settings only), orange is all of GitHub. The blue and orange bars track each other, mostly:
Two findings jump out.
First, 79 is dead. People like longer lines. Only 10.6% of projects that bother to configure a limit choose 79 or 80. Meanwhile, 61.6% of explicitly configured projects allow 100 characters or more.
Second, among the top-starred repos, the most common explicit choice is 120, but among all repos, the most common choice is 100.
GitHub-wide, 100 comes out first with 34% ("line-length = 100" alone returns ~175,000 hits, versus ~110,000 for 88 and ~71,000 for 120), while among the top-starred repos 120 leads.
So the long tail of ordinary repositories leans 100, the most-starred projects lean 120.
Which number is “most common” genuinely depends on which population you ask.
So where does that leave us?
I went in expecting the data to crown a single number, but it’s pretty scattered. 120 leads among the top-starred projects, 100 leads GitHub-wide, and maybe unsurprisingly, 88 dominates if you count everyone who silently accepts their formatter’s default.
What the data is unambiguous about is direction. Hardly anyone chooses 79 or 80 anymore. Most projects that make a deliberate choice go beyond Black’s 88 as well: 62% of explicit limits are 100 or more, the median explicit setting is exactly 100.
The numbers
| limit | top-starred repos | share | GitHub-wide hits | share |
|---|---|---|---|---|
| 79 | 93 | 4.9% | 27,656 | 4.4% |
| 80 | 106 | 5.6% | 14,520 | 2.3% |
| 88 | 445 | 23.4% | 166,656 | 26.5% |
| 90 | 21 | 1.1% | 5,166 | 0.8% |
| 99 | 49 | 2.6% | 15,988 | 2.5% |
| 100 | 349 | 18.3% | 214,496 | 34.2% |
| 110 | 23 | 1.2% | 10,017 | 1.6% |
| 119 | 70 | 3.7% | 16,848 | 2.7% |
| 120 | 539 | 28.3% | 137,216 | 21.9% |
| other | 210 | 11.0% | 19,264 | 3.1% |
Top-starred: 1,905 repos with explicit config (of 4,847 total). GitHub-wide: ~628,000 file-level hits across three config syntaxes.
Methodology, scripts, and the full dataset are on GitHub. Snapshot 2026-08-21; sample = 4,847 non-fork, non-archived GitHub repos, primary language Python, >= ~1,450 stars, pushed within one year.
Caveats: I only considered a fixed set of eleven root-level config filenames, and monorepos are read at the root only, so a limit set in a subpackage’s pyproject.toml, under a nonstandard filename, or in CI flags is invisible and counts as “no config”; “no config” repos may still have team norms.
Related topics: