The 80 char line length suggestion sort of feels like it’s from a different era. Does it still make sense to continue to soft-enforce this limit within changes to code or for cpython itself?
Sometimes when looking at code, I’ve had to do some odd things to get a line to fit in 80 chars, especially in tests with a couple levels of indentation eating the first 8 chars. These odd things can sometimes lead to worse readability for the sake of hitting less than 80 chars.
So I guess my idea is either drop the requirement for 80 characters (in cpython) or less per line or update the 80 characters to something more fitting to today’s terminals.
In a perfect world a PEP would be written to update the recommended line length, but that seems like a lot to change 80 to something wider.
As much as I agree with you that the 80-character limit feels rather constraining when coding in Python where deep indentation is often unavoidable with nested loops, closures, context managers and exception handlers, I also find the current width setting of the Discourse forum to be just about perfect, able to accommodate a pair of side-by-side 80-character-wide regions for both writing and preview.
If we increase the recommended width limit by any amount we’ll have to either increase the widths of the side-by-side regions in Discourse accordingly and lose support for some lower-res displays or settle with viewing some codes in Discourse with lines wrapped around.
This drawback is relatively minor compared to what we can gain from a more comfortable coding experience though, so overall I’m +0.9 for the idea.
The CPython standard library limit is 79 characters for Python code, not 80, and PEP 8 gives more justifications, along with allowance for teams to choose a longer limit up to 99 if they can all agree.
Limiting the required editor window width makes it possible to have several files open side by side, and works well when using code review tools that present the two versions in adjacent columns.
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.
Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the line length limit up to 99 characters, provided that comments and docstrings are still wrapped at 72 characters.
The Python standard library is conservative and requires limiting lines to 79 characters (and docstrings/comments to 72).
This is the guide for the standard library of CPython. And PEP 8’s first section always applies. You can do whatever you want in your code (I use Black’s 88 in most other projects).
I still like this limit on this era’s screen, with 4 files open side by side.
Terminal widths from bygone eras weren’t driven only by technical limitations.
In typography, the ideal length of a readable line is 40-75 chars. Not sure what’s the proper way to adjust that for indentation, a monospaced font, and displaying code rather than prose, but 80 feels “just right” to me.
Also, a consistent limit – whatever the exact value is – lets me avoid fiddling with the column widths on my screen as I open different files.
Indentation consisting of whitespaces shouldn’t count against the number of characters in a readable line IMHO.
Take the following line as an example. It’s 62 characters wide if you don’t count the indentation, or 94 characters wide if you do, and I find it perfectly readable (when viewing it in an IDE) because its effective width still falls within the recommended 40-75 chars:
I think whitespace does count here. It gives context on how many levels deep the indent is, and our general location in the code. Ignoring whitespace encourages deeply-nested “arrow code”, producing more complex code and impairing readability .
(The Linux kernel uses 8-char indents because if the indent is pushing your code too far off to the right, that’s a sign you should refactor.)
For me, this is rather an example of a too-long line, if anything, because the end of _symtable.TYPE_FUNCTION: is not shown, and I need to horizontally scroll left and right, which is a distraction from reading the code:
Even I, clinging to my Emacs, personally uses wider screens and windows these days, so I bust through that 80 character limit on my own code.
That said, for left-to-right readers, the farther code is pushed to the right the more difficult it gets to read. I know we drew on studies about that back in the original PEP 8 days, but I don’t have any handy and they’re probably out of date anyway.
I still think it makes sense to keep the PEP 8 recommendation. It’s a social contract in a sense because it helps keep the stdlib commonly readable. I know that tools and teams often hobgoblinishly refer to PEP 8 guidelines for their own projects, but the paragraph about consistency comes to mind, so do what’s right for the majority of folks working on your own code[1].
like e.g. the way I squint my eyes and rely on reformatters to turn the one true right way of single quotes into harder to read and type double quotes ↩︎
I think a simple approach for line length would be to be descriptive rather than prescriptive. Comb through the 100 most popular Python projects and inspect their line width (using pyproject.toml’s linter options, or .editorconfig’s line length option). Take the average every year and prescribe a similar value to the average.
PEP 8 is the style guide for the standard library. As such it is descriptive, because the stdlib follows the existing recommendation. Other projects can choose to follow what PEP 8 says or use their own line length guideline.
I haven’t seen any justification for changing the rules for the stdlib. I’m not saying there aren’t any, just that abstract arguments about being more “modern”, or complaints about the existing guide being awkward for non-stdlib code, simply aren’t relevant to PEP 8’s purpose of being a style guide for the stdlib.
You can argue that the community has adopted PEP 8 and it’s now wider than the stdlib. But is it? The community emphatically hasn’t adopted everything - black and ruff don’t impose the 79-character line length, for a start. And no-one seems to follow the “Foolish Consistency” section at all So it’s not like people are constrained by what PEP 8 says, this sort of debate feels more like people asking for validation that where they don’t like PEP 8’s rules, that’s OK. But it is OK, because you don’t have to follow PEP 8 in the first place - and PEP 8 explicitly says that…
With test code, when using unittest, it would help if you could use assert_equal instead of self.assertEqual. As a bonus naming would be PEP 8 compatible. What it would take to get the asserts module added to the standard library?
My point was simply what is Pythonic is what people are generally doing (descriptivism). I think it’s reasonable for the standard library to follow this standard.
Instead of trying to debate what is Pythonic every few years, it’s more reasonable to do what dictionaries do with language.
IMO, “Pythonic” isn’t about the sorts of details you get in a style guide. And I don’t think it’s reasonable for the standard library to follow community trends in coding style, any more than it’s necessary for the community to follow the stdlib’s rules.
PEP-8 is the style guide for the standard library. It is not the style guide that you need to use. It is, believe it or not, not the style guide used by most of the world. It does serve as a basis for that, however. And one of the first things many groups using it as the basis for their style guide do is tweak the line length to be appropriate for them. In my team’s case that’s 120 characters. I’ve been at places where it was 100 and places where it was 140. The goal of PEP-8 isn’t to prescribe how anyone styles their code unless they are writing code for the Python standard library.
This would give us a new line length (probably) every year! Python is a 30-year-old project, we don’t want to change line lengths every year.
Style guides aren’t the same as dictionaries. A newspaper has a (language) style guide, which is a prescriptive guide on how to use language. This guidance does of course change, but not in the same way a dictionary is a descriptive and explains how meanings of words change.
So it’s not like people are constrained by what PEP 8 says, this sort of debate feels more like people asking for validation that where they don’t like PEP 8’s rules, that’s OK. But it is OK, because you don’t have to follow PEP 8 in the first place - and PEP 8 explicitly says that…