[Python-ideas] PEP 8 update on line length

[Christopher Barker]

>
>
> Chris, the convention to limit text to somewhere around 60-80 characters
> predates old terminals by *literally centuries*.


Not for code, it doesn’t— and centuries ago, there were other technical
issues on play for papermaking, hand writing, and typesetting.

>
(And did they ever stop to wonder why those old terminals
> standardized on 80 columns?)


CRTs were small and low resolution?

A 200 char line would have been very expensive back in the day, and I’m
pretty sure the old tractor feed paper terminal I first learned to code on
was a lot more than 80 char wide.

But now that you mention it, I suspect the 80 char punch cards had an
influence.

How many of us still type on QWERTY keyboards? Even on a phone, like I am
now.

The point is that we conform to s lot of conventions without re-adding
whether the original reasons for those conventions apply. And no one on
this thread has cited a study about optimum line length for readability of
code. I have no idea if that’s ever been done — but that is the question at
hand.

“Typesetters hundreds of years ago used less than 80 chars per line, so
that’s what we should do for Python code now” is a pretty weak argument.

> Go back and read the thread.

I have read the thread. And Raymond made a pretty good argument for why, in
some cases, a shorter line limit is a problem— and I have had much the same
experience.


and the nuisance value of splitting a conceptual
> line of code over multiple physical lines.


I think one key question is whether it’s a nuisance, or actually makes some
code harder to read.

>
> 1. 79 characters is *very generous* for most lines of code;


I’ve found a common exception for this is string literals and trailing
comments.

And I often prefer 80+ char trailing comments to an extra comment line.

2. When a single line goes beyond 80 columns, it often wants to go a
> long way beyond.


Often True, but I’ve found setting my linter to 95 char makes a big
difference in my code


> Opinion: we really shouldn't be encouraging people to write long complex
> lines of code.


Agreed — but as you point out, those are often MUCH longer, so pushing the
line limit to < 100 chars doesn’t really change that.

4. But one notable exception to this is the case where you have a long
> format string, often passed to "raise Exception",

...

> These are often indented four or five levels deep, and they really are a
> pain-point.


Oh yeah, that was Raymond’s point, and I concurred and emphasized it.

>
> Opinion: common sense should prevail here. If you have a line "raise
> ValueError(...)" which would reach 80 or even 90 characters, don't let
> PEP 8 alone tell you otherwise.


Yup - the trick here is that it’s hard to define clearly in a style guide,
and even harder in a linter.

One issue with all this is that there’s been a move toward automated
enforcement (or checking) of style. Which I think is an overall good thing,
but then it’s hard to allow judgement as well.

But if you have a more substantial code that exceeds 80 columns, that's
> a code smell and you ought to think long and hard before breaking it.


My reading of your points above is that the really smelly code is well over
80 chars, so having a slightly larger limit would work fine as well.


Proposal:
>
> - keep PEP 8's current recommendation;


As long as that includes the “ you can raise it to up to 100 char, sure :-)

>
> - but remind people that the rule can be relaxed for lines that are
> conceptually simple, such as the "raise Exception(...)" pattern;


It would be nice, if possible, to clearly define this relaxation.

- and also remind people that long *complex* lines are an anti-pattern.
> Such complex lines can be improved by splitting them over multiple
> lines, and should be.


Not sure that’s needed, but why not?

>
> That effectively says "any amount of complexity is OK in a single line,
> so long as it remains below X columns". I'd rather people look at the
> line and decide "this is too complex, split it" or "it's just a format
> string (or whatever), let it be".


Agreed — you can have too much complexity in 80 char. Which is why I think
the 80 char limit is about what fits on a screen, not complexity.

-CHB
-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190222/0c7e4e95/attachment.html>