[Python-ideas] PEP 8 update on line length

Brendan Barnwell brenbarn at brenbarn.net
Thu Feb 21 02:26:51 EST 2019


On 2019-02-20 18:41, Christopher Barker wrote:
> God no! I HATE that style -- for me, it makes it MUCH harder to read --
> even more so if the variable names are a bit longer.
>
> But if you are going to do it, for the love of god, use more than four
> spaces! four spaces is one indentation, one indentation is how a code
> block is delineated in Python -- this is NOT a code block. It should not
> look like one.

	I feel the complete opposite.  "One indentation" is the only unit in 
multiples of which anything should ever be indented.  Using arbitrary 
"indentation" to visually line things up is horrible.  Everything gets 
indented by an integer number of indentation levels.

	It was mentioned earlier on this thread, but I think the real problem 
is editors.  Specifically, people have become used to certain editor 
behaviors and conventions which are not actually that great, and as a 
result editors have not emphasized features which would be better.  Even 
more specifically, people have not insisted that editors be designed to 
support a reader-oriented, rather than writer-oriented, approach to code 
display.  In other words, visual details how the code is displayed 
should be up to person reading the code, not the person who wrote it.

	Instead, people have apparently for a long time insisted on the 
reverse, namely editors which format things as the code is written, by 
inserting actual characters in the file to make things like up visually. 
  Characters shouldn't be in the file to make things like up visually; 
they should be there for their semantic importance.  If that is done, 
then the editor can render those semantics in different ways according 
to the viewer's preference.

	The problem is that editors don't do this, because people have somehow 
gotten the idea that this would be a bad thing.  So instead we have to 
argue over things like this, because whatever purely cosmetic choices 
one person makes in indenting his or her code become baked into the 
actual bytes of the file, and cannot be rendered differently later 
according to the preferences of a different viewer.

	I've rather forlornly given up on dealing with any of this.  I use an 
editor that VISUALLY wraps long lines and maintains the indentation on 
the wrapped portion, without changing the bytes in the file.  I make my 
lines as long as I want, inserting linebreaks only where they have a 
semantic reason to be (such as between multiple long conditions in an 
"if").  Everything is fine, until someone else looks at the code, and 
they have an editor that is only designed to display code that has the 
formatting baked into the whitespace.

	As a result, I consider this issue pretty much moot.  There is no 
reason for the line length limit to be set to 100 or 120 or anything 
else.  There are already too many problems with PEP 8 that stem from a 
desire to use whitespace for visual alignment rather than semantics 
(such as using spaces instead of tabs).  So I just basically ignore PEP 
8 and follow my own style, which happens to overlap in some respects 
with PEP 8 and diverge from it in others.

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."
    --author unknown


More information about the Python-ideas mailing list