I think you’re mistaken on this. While style guides are prescriptive, what they prescribe is based on how people write in practice. The King’s English, for example, is replete with examples of good and bad writing.
Well, you don’t have to change every year, or at all. Honestly, it’s such minor convenience or inconvenience.
… and yet, when we say we don’t see the need to change PEP 8, we still get discussions like this every year (or probably more). It would be nice to also not have to go through the same old debates as well.
We could just make a rule that all requests to change line length in PEP 8 get a terse response and then the thread gets locked. That would save us going through the same old debates repeatedly. Of course, that miiiiight come across as a bit unwelcoming.
Fair enough.
My suggestion would be to rename the PEP from “Style Guide for Python Code” to " Style Guide for Python Code in the Standard Library". I know that it says so in the lede, but not everyone reads the lede.
Also, consider clarifying the line length section:
“Limit all lines to a maximum of 79 characters. (This PEP only relates to the standard library; many modern Python libraries choose wider line lengths.)”
This acknowledges that while many people do use PEP8 for their libraries, this is a point on which libraries very commonly differ from the standard library.
Right. 
How about this wording, perhaps?
“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.”
Would that cover it?
The PEP is about the standard library, so I don’t think you should give any advice about non-library code.
First, because it’s out of scope, but also because people are already complaining about having to discuss this. If you make a recommendation like that, you invite people to comment on it every year.
Also, I have no idea where you got 99 and 72.
I think it’s better to just let people decide on their own. If you want to give subtle guidance, compile a list of what other major projects have chosen, along with the date on which the project was started (to give a feel for evolution).
For example, typing-extensions uses 90, mypy uses 99, typeshed uses 130, etc.
The wording that I gave there is what’s currently in the PEP. None of this is hypothetical. It has all been discussed before, many times.
This sounds like you’re making a recommendation for code not in the standard library. I don’t think that’s a good idea no matter by whom or how many times it’s been discussed.
Disagree all you like, but that paragraph has been in the document since 2013. :shrug:
Fair enough. I’m a descriptivist when it comes to style. As you can see, modern projects don’t follow the 72 character recommendation, and the typeshed doesn’t even follow the 99 character recommendation (for good reason).
I had read PEP 8 when I began wrapping AutoCAD’s ObjectARX, which is C++
I found it too difficult to comply.
Adding underscores would make naming too different from the original documentation, I.e.
BlockTableRecord.is_from_external_reference
If the line length were adhered strictly, people would start using undescriptive variable names. Just a basic function breaks the rules
#len 84
@Ap.Command()
def doit2():
try:
database = Db.HostApplicationServices().workingDatabase()
model = Db.BlockTableRecord(database.modelSpaceId(), Db.OpenMode.kForWrite)
except Exception as err:
traceback.print_exception(err)
The conversation has sort of gone off from my original idea/thought here.
I’m not here to debate PEP8 itself or how it applies to other code. I’m asking about the consideration for changing the application of it specifically in the standard library (or at least the cpython implementation). Whether or not folks consider PEP8 as gospel for other pieces of code is a different conversation.
I agree that there should be consistent limits in a given entity (like the standard library) but I don’t think it’s fully consistent as is. Like some lines break the 79 or 80 character limit already. If there is a hard limit, why doesn’t CI fail on the longer lines?
In terms of diff viewers and the like, that’s all subjective to the viewport. Back in the day, 640x480 was common. Now 1920x1080 and bigger are common. Aspect ratios are generally widescreen now. Why not change the rules along with things like this? It’s a bit lonely for the right half of my screen with only the left half in use. 
There are a number of good reasons to ignore a directive.
This was all answered above. Read the entire thread, don’t dismiss it as having gone off topic.
Please consider the limitations of people with disabilities.
My suggestion of an effective line length was specifically meant to expand on your citation of Line length - Wikipedia, where the reason behind a recommended line length is “If the lines are too short then the text becomes disjointed; if they are too long, the content loses rhythm as the reader searches for the start of each line.”
The start of each line that a reader searches for is the first printable character in the line, not including the leading whitespaces.
I think a good middle ground would be to allow 75 characters of effective line length, but also a 99-character maximum line length including indentation to avoid horizontal scrolling. Arrow code can be avoided with the 99-character maximum line length too.
It’s because of PEP-8’s recommendation of a 79-character line length that we have this width setting in Discourse and that you have to scroll horizontally for a 94-character wide line.
The point I was trying to make with that link to the line of code is to show that a reader would have no problem reading the line with an effective line length of 62 characters because it follows the Wiki article’s recommendation, and that there would be no horizontal scrolling needed with a modern viewer designed for a 99-character line length if PEP-8 is to be updated so.
But yes, although I ususally view diffs in non side-by-side views, I do see the need for side-by-side views as a good argument against a change to a longer line length.
Consdier me +0 now then. Thanks.
PEPE8 is for core developers, I am sure if they had a problem with it, they would start the discussion. PEP8 imay not be for everyone - it says that. One is OK to make changes to ones own, non-stdlib, work. Some companies, like Google have their own rules, one might adopt a ruleset from an admired company and gain validation for ones choice that way?
Can you elaborate on this comment? I’m not sure what disability or situation or comment you’re referring to.
I guess that’s fine though the thought came to me from making a recent change/PR and getting it merged into cpython. Getting the line length down for my lines while some other lines already crossed the limit seemed a bit weird to me. A bit discouraging in a sense.
I thought maybe the rule should either apply universally (via ci checks) or not at all.
At the end of the day I guess if the core team doesn’t want thoughts or conversations like this from non core contributors, I guess the thread can be closed. Though I don’t think that would be too inclusive.
I take that comment to refer to the way that line length impacts disability accommodation for folks with reduced vision. Longer lines impede people’s ability to increase fonts to comfortable sizes without wrapping.
So keeping lines to 80 or 88 characters (flake8-bugbear’s “speed limit” rule is nice) is good for keeping the code itself more accessible.
Personally, I use vertical splits usually sized to around 90 chars and find it disappointing when things wrap.
I think you were correct in noting that your original comment about “should the standard library itself change” has been mistaken for something else.
I have no personal opinion on the matter – but I think the core devs aren’t enthusiastic about updating PEP8 and that should probably be enough.
Shorter lines are more readable.
If you have low vision, you might zoom your display to make the text bigger.
The WCAG AAA guidelines has guidance about blocks of text, rather than code, but some of this also applies to code:
For people with some reading or vision disabilities, long lines of text can become a significant barrier. They have trouble keeping their place and following the flow of text. Having a narrow block of text makes it easier for them to continue on to the next line in a block. Lines should not exceed 80 characters or glyphs [of non-CJK].
There are physical Braille displays that have distinct cells that raise up dots to display a single row of text, and range between 16 and 80 characters.