PEP 8 : Maximum line Length :

[Chris Angelico]

On Thu, May 15, 2014 at 10:32 PM, Johannes Bauer <dfnsonfsduifb at gmx.de> wrote:
> Personally I find overly narrow code (80 cols) to be much *harder* to
> read than code that is 100 cols wide. Keep in mind that even if the
> break is at 100 cols, lines will rarely exceed that limit. And if they
> do to *understand* the code, the further down the line it is the less
> important are the details usually.

The limit of human readability is generally given to be somewhere in
the range of 60-120. It's not a single specific value that's exactly
the same for everyone; personally, I like my lines of code to be a bit
longer than 80, and will happily go to 90-100, but in the interests of
interoperability, it's helpful to standardize on one common value -
especially for large shared codebases.

You're arguing against the specific value of 80, but 100 is still
pretty close to that. There are two key boundaries: the point at which
your eye can no longer comfortably read the text, and the point at
which you need to scroll horizontally. The latter of course depends on
your screen, but it's an EXTREMELY important barrier; the former is
the "soft" boundary, as you won't instantly know when you're over it.
(The two can be in either order, of course. I could easily read 90
char lines, but if I'm in a standard 80x24-25 terminal window, that's
going to scroll.) Both boundaries are almost certainly exceeded by a
500-character line; if you're doing your code like that, you obviously
do not want anyone reading it. [1] Whether you cut it off at 70, 80,
100, or some other figure, you still want to put some kind of limit on
it.

ChrisA

[1] That doesn't mean "never do this". I've sometimes had code with
insanely long lines - for instance, an auto-generated list of names -
and it wasn't meant to be human-readable. Breaking it onto multiple
lines would have complicated matters unnecessarily, and if you wanted
to read the code, you should be reading the other file anyway.