Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #71445 > unrolled thread

PEP 8 : Maximum line Length :

Back to article view | Back to comp.lang.python

Contents

  PEP 8 : Maximum line Length : Ganesh Pal <ganesh1pal@gmail.com> - 2014-05-13 12:37 +0530
    Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-13 04:52 -0700
      Re: PEP 8 : Maximum line Length : Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-13 13:46 +0000
        Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-14 08:55 +1000
          Re: PEP 8 : Maximum line Length : Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-05-14 12:24 +1200
        Re: PEP 8 : Maximum line Length : Terry Reedy <tjreedy@udel.edu> - 2014-05-14 17:09 -0400
      Re: PEP 8 : Maximum line Length : albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-14 22:53 +0000
        Re: PEP 8 : Maximum line Length : Gary Herron <gary.herron@islandtraining.com> - 2014-05-14 17:15 -0700
        Re: PEP 8 : Maximum line Length : Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-15 02:16 +0100
          Re: PEP 8 : Maximum line Length : Roy Smith <roy@panix.com> - 2014-05-14 22:12 -0400
            Re: PEP 8 : Maximum line Length : Dave Angel <davea@davea.name> - 2014-05-15 08:16 -0400
        Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-14 19:36 -0700
          Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-15 12:43 +1000
            Re: PEP 8 : Maximum line Length : Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-05-15 14:32 +0200
              Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-15 16:07 +0300
                Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-15 23:31 +1000
                  Re: PEP 8 : Maximum line Length : alister <alister.nospam.ware@ntlworld.com> - 2014-05-15 13:38 +0000
                    Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-15 23:44 +1000
                      Re: PEP 8 : Maximum line Length : alister <alister.nospam.ware@ntlworld.com> - 2014-05-15 19:29 +0000
                Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-15 06:53 -0700
                  Re: PEP 8 : Maximum line Length : Roy Smith <roy@panix.com> - 2014-05-15 09:58 -0400
                    Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 00:14 +1000
                    Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-15 07:15 -0700
                      Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-15 17:29 +0300
                        Re: PEP 8 : Maximum line Length : Skip Montanaro <skip@pobox.com> - 2014-05-15 09:38 -0500
                        Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 00:42 +1000
                        Re: PEP 8 : Maximum line Length : Terry Reedy <tjreedy@udel.edu> - 2014-05-15 17:50 -0400
                        Re: PEP 8 : Maximum line Length : MRAB <python@mrabarnett.plus.com> - 2014-05-16 01:05 +0100
                    Re: PEP 8 : Maximum line Length : Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-15 17:18 +0100
                  Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-15 17:12 +0300
                    Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 00:24 +1000
                      Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-15 17:36 +0300
                        Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 01:03 +1000
                    Re: PEP 8 : Maximum line Length : Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-16 06:25 +0000
                      Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-16 16:54 +1000
                      Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-16 10:00 +0300
                        Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 17:39 +1000
                          Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-16 12:18 +0300
                            Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 19:40 +1000
                              Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-16 13:48 +0300
                      Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 17:36 +1000
                Re: PEP 8 : Maximum line Length : Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-16 00:21 +0000
              Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-15 23:27 +1000
                Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-15 06:58 -0700
                  Re: PEP 8 : Maximum line Length : Terry Reedy <tjreedy@udel.edu> - 2014-05-15 18:21 -0400
                    Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-15 17:06 -0700
                      Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-16 10:21 +1000
                        Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-15 20:03 -0700
                          Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-16 16:12 +1000
                      Re: PEP 8 : Maximum line Length : Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-16 07:05 +0000
                  Re: PEP 8 : Maximum line Length : Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-16 02:25 +0000
              Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-16 09:32 +1000
          Re: PEP 8 : Maximum line Length : Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-15 03:28 +0000
            Re: PEP 8 : Maximum line Length : Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-15 20:18 -0400
          Re: PEP 8 : Maximum line Length : Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-15 04:44 +0100
    Re: PEP 8 : Maximum line Length : Roy Smith <roy@panix.com> - 2014-05-13 08:09 -0400
      Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-13 22:26 +1000
        Re: PEP 8 : Maximum line Length : Roy Smith <roy@panix.com> - 2014-05-13 20:51 -0400
      Re: PEP 8 : Maximum line Length : Tim Chase <python.list@tim.thechases.com> - 2014-05-13 07:52 -0500

Page 3 of 3 — ← Prev page 1 2 [3]

#71647

On Fri, May 16, 2014 at 4:25 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Containing *what*? You can't just wave your hands and say "binary". What
> sort of binary file? Perhaps a JPEG file, where red triangles of
> different sizes represent keywords. Variable names can be encoded using a
> pattern of purple dots. Expressions and blocks of code can be formed by
> joining components with lines. Operators by squares of different colours
> (green means +, blue means -, etc.).

http://www.dangermouse.net/esoteric/piet.html

ChrisA

[toc] | [prev] | [next] | [standalone]

#71632

On Thu, 15 May 2014 16:07:54 +0300, Marko Rauhamaa wrote:

> Johannes Bauer <dfnsonfsduifb@gmx.de>:
> 
>> I don't know why anyone would force a display issue onto everyone.
> 
> Well, if I have to work with your code, you are forcing your style on
> me.

+1


>> It imples the arrogant stance that every human being has the exact way
>> of reading and writing code. Everyone can configure her editor to what
>> she wants (including line breaks and such).
> 
> That's a good point: why aren't we just exchanging AST's and configuring
> the editor to display them in our preferred format?

Oh, I hope not. Sometimes information is carried by the layout. For 
example, if I write a class:

class Spam:

    def foo(self): ...
    def bar(self): ...
    def baz(self): ...

    def foobar(self): ...


then without me saying anything, the reader should realise that foo, bar 
and baz, but not foobar, go together in a weak sense. If it were a strong 
sense, foobar ought to go into a separate class.

A real example: writing getters and setters for property. Particularly if 
they are one or two line methods, I'll usually run them together with no 
separating blank lines to emphasize that they belong together.

ASTs often don't include comments, so that's a problem.


> Well, we're not there yet.
> 
> Objective readability is not the main issue here, IMO. It's the screen
> estate. I know the idea of "windows" is fast disappearing from modern
> ("mobile") computing; you have "apps" instead that commandeer the whole
> screen. Personally, I find that a big step backwards.

Yes. In my opinion, mobile computing is a huge step backwards for 
personal control of your own hardware, usability, and power. In my 
opinion, people will look back at the first decade of the 21st century as 
the golden age of personal computing.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#71599

On Thu, May 15, 2014 at 10:32 PM, Johannes Bauer <dfnsonfsduifb@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.

[toc] | [prev] | [next] | [standalone]

#71606

On Thursday, May 15, 2014 6:57:26 PM UTC+5:30, Chris Angelico wrote:
> 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.
> 

Thanks Chris for some sanity

As far as I can see the votaries of the mystical 79 have yet to explain
how/where it appeared from

JFTR the OP asked how to shorten a line and the shortest so far is what I 
suggested

[toc] | [prev] | [next] | [standalone]

#71627

On 5/15/2014 9:58 AM, Rustom Mody wrote:

> As far as I can see the votaries of the mystical 79 have yet to explain
> how/where it appeared from

As has been explained before, and is implied in the PEP, 79 = 80 - 1.
80 chars - 1 character width cursor leaves 79 non-cursor characters. 
When <enter> is hit, the cursor replaced with \n. So you can think of 79 
as 79 visible + \n = 80.

PEP 8 says "The limits are chosen to avoid wrapping in editors with the 
window width set to 80," and goes on about dynamic wrapping or not. To 
put is another way, all 80 char terminals work with 79 visible chars. 
Some but not all work with 80 visible, and some work with 80 on all 
lines except the last.

I admit that this would have been clearer when most everyone reading it 
would have had some experience with 80 char sceens (including DOS). 
Still, did you really not notice that 79 = 80 - 1?

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#71629

On Friday, May 16, 2014 3:51:27 AM UTC+5:30, Terry Reedy wrote:
> On 5/15/2014 9:58 AM, Rustom Mody wrote:
> 
> 
> > As far as I can see the votaries of the mystical 79 have yet to explain
> > how/where it appeared from
> 
> 
> 
> As has been explained before, and is implied in the PEP, 79 = 80 - 1.
> 80 chars - 1 character width cursor leaves 79 non-cursor characters. 
> When <enter> is hit, the cursor replaced with \n. So you can think of 79 
> as 79 visible + \n = 80.
> 
> 
> 
> PEP 8 says "The limits are chosen to avoid wrapping in editors with the 
> window width set to 80," and goes on about dynamic wrapping or not. To 
> put is another way, all 80 char terminals work with 79 visible chars. 
> Some but not all work with 80 visible, and some work with 80 on all 
> lines except the last.
> 
> 
> 
> I admit that this would have been clearer when most everyone reading it 
> would have had some experience with 80 char sceens (including DOS). 
> Still, did you really not notice that 79 = 80 - 1?

The claim being made is that 79/80 is a fundamental, cognitive limit and has 
no relation to technological changes.

[toc] | [prev] | [next] | [standalone]

#71633

Rustom Mody <rustompmody@gmail.com> writes:

> The claim being made is that 79/80 is a fundamental, cognitive limit
> and has no relation to technological changes.

Who has made that claim, and where? You appear to be attacking a straw
man.

Rather, I've claimed that the conventional lime length limit is *based
in* the real cognitive limits of human reading comprehension — and that
technologies have been designed with corresponding limitations.

Nowhere have I claimed 79 or 80 are somehow fundamental or encoded in
human cognition, and I have seen no-one else claim that. Please try to
work within your own cognitive limits and read what people write for
comprehension.

-- 
 \      “As soon as we abandon our own reason, and are content to rely |
  `\       upon authority, there is no end to our troubles.” —Bertrand |
_o__)                                Russell, _Unpopular Essays_, 1950 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#71636

On Friday, May 16, 2014 5:51:21 AM UTC+5:30, Ben Finney wrote:
> 
> 
> Rather, I've claimed that the conventional lime length limit is *based
> in* the real cognitive limits of human reading comprehension -- and that
> technologies have been designed with corresponding limitations.
> 
> 
> Nowhere have I claimed 79 or 80 are somehow fundamental or encoded in
> human cognition, and I have seen no-one else claim that. Please try to
> work within your own cognitive limits and read what people write for
> comprehension.
> 

You said this:

> The 80 character line limit is *not* driven by a limitation of computer
> technology; it is driven by a limitation of human cognition. For that
> reason, it remains relevant until human cognition in the general reading
> population improves. 

And you answered:

> Until then may we relegate '79' to quaint historical curiosities...??

with

> Not until the general capacity of human cognition advances to make
> longer lines easier to read.

[toc] | [prev] | [next] | [standalone]

#71641

Rustom Mody <rustompmody@gmail.com> writes:

> You said this:
>
> > The 80 character line limit is *not* driven by a limitation of
> > computer technology; it is driven by a limitation of human
> > cognition. For that reason, it remains relevant until human
> > cognition in the general reading population improves.
>
> And you answered:
>
> > Until then may we relegate '79' to quaint historical
> > curiosities...??
>
> with
>
> > Not until the general capacity of human cognition advances to make
> > longer lines easier to read.

Indeed. Once again: Human cognition has limits, including limits on
reading speed and reading comprehension as the length of a line of text
increases beyond a threshold.

You have caricatured that as some kind of statement that every human has
a fundamental 79-column limit, which no-one has claimed.

If you can't see the difference between what I and others have been
saying about limits on human cognition, versus your caricature, then I
can only leave you to re-read until you do understand. And I'll thank
you not to straw-man people's positions.

-- 
 \             “Dyslexia means never having to say that you're ysror.” |
  `\                                                        —anonymous |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#71646

On Thu, 15 May 2014 17:06:13 -0700, Rustom Mody wrote:

> The claim being made is that 79/80 is a fundamental, cognitive limit and
> has no relation to technological changes.

I don't believe anyone has made that claim. You are reading a statement 
about general (typical, average) behaviour, and turning it into an absurd 
statement of a "fundamental" (your word) which applies to every single 
human being on earth.




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#71635

On Thu, 15 May 2014 06:58:53 -0700, Rustom Mody wrote:

> As far as I can see the votaries of the mystical 79 have yet to explain
> how/where it appeared from

You're either trolling, or haven't been reading this thread in any 
detail. That's already been explained, repeatedly both in this thread and 
many times over the years: 79 is one less than 80, which is the standard 
width of many editors, which in turn comes from old dedicated terminals.

Given your use of deliberately provocative terms like "votaries" and 
"mystical", I would say you're trolling.

On the chance that you are asking an honest question, there's nothing 
"mystical" or magical about the number 79, or 80. 80 is a de facto 
standard. Had history turned out a bit different, that standard might 
have been 90 characters, or 70. Less likely (because people 
psychologically have a preference for multiples of ten over "random" 
numbers) it could have been 65, or 93, or any number somewhere in that 
range of 60 to 100 or thereabouts.

But once a standard is established, even an arbitrary standard like 80 
columns -- but not *entirely* arbitrary -- there is value in sticking to 
it *just because it is the standard*. There's nothing "mystical" about 
driving on the left hand side of the road (on the right hand side for 
Americans), but whatever choice everyone else has made, you really ought 
to do the same. Following the same standard simply makes interoperability 
easier and reduces friction.

But as I said, 80 isn't *entirely* arbitrary. 8 characters would be too 
few; 800 would be too many. Approximately 60 to 100 characters or 
thereabouts is the "Goldilocks" zone of "not too few, not too many" for 
most texts.

Think of it this way: every time the reader has to scroll horizontally, 
consider that as a page fault (it's an order of magnitude slower than 
scanning with the eyes). Every time a single logical expression has to be 
split over two lines, that's also a page fault. Every time you read a 
line of complicated code that does too much, that's also a page fault. We 
want to minimize the number of page faults.

A limit of 60 characters would minimize the number of horizontal 
scrolling page faults (hardly anyone has their editor to display fewer 
than 60 characters!), but increase the number of expression-splitting 
page faults. A limit of 120 characters would reduce the number of 
expression-splitting page faults, but increase the number of horizontal-
scrolling faults, and encourage people to write long lines of complicated 
code that does too much. Somewhere in between is a range that minimizes 
the number of page faults, hence maximizes readability.

There's unlikely to be "One True Best Answer" to maximize readability at 
N characters, because maximum readability is dependent on the context. 
One can only hope to get close to maximum readability for a range of 
typical text, including code. That's likely to be around 80 characters, 
which fits nicely with the historical standard. Reducing that to 80-1=79 
means you're protected from "off-by-one" errors in either your counting 
or your editor.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#71628

Johannes Bauer <dfnsonfsduifb@gmx.de> writes:

> On 15.05.2014 04:43, Ben Finney wrote:
> > Rustom Mody <rustompmody@gmail.com> writes:
> > 
> >> Until then may we relegate '79' to quaint historical curiosities
> > 
> > Not until the general capacity of human cognition advances to make
> > longer lines easier to read.
>
> I find it surprising how you can make such a claim about the whole of
> humanity (!) without even feeling the need to have a pro forma study
> to back it up.

This is an informal discussion forum. Merely because I don't produce
citations every time I mention a fact doesn't imply that I'm not basing
my assertions on fact.

Here is one such study
<URL:http://www.psychology.nottingham.ac.uk/staff/mxh/Papers/Dyson%20&%20Haselgrove%20%282001%29.pdf>.
But there is plenty of room for uninformed diverity of opinion
<URL:http://skeptics.stackexchange.com/questions/5625/are-shorter-lines-easier-to-read>.

The point is less about hard evidence about *precise* limits; I make no
claim about the superiority of 80 columns or 93 columns or 55 columns or
whatever.

Rather, the point is rather that human cognition *does* have limits, and
those limits are at the basis of limits we choose to impose on text
layout.

Those who claim “terminals just magically happened to be 80 columns wide
and we were slaves to that limit” have it completely backward: the
limits were imposed *onto* the terminals by human makers, based on their
understanding of the cognitive limits of the humans reading from them.

Those limits are with us still, and to my knowledge have not improved
with recent human generations.

> Also, not everything that applies to prose also equally applies to
> code.

If you're going to counter evidence of general human reading cognition
by making special claims about code, that would need to be backed up
with specific evidence.

> Personally I find overly narrow code (80 cols) to be much *harder* to
> read than code that is 100 cols wide.

I counter your anecdote with my own: I find 80 columns to be quite long,
and prefer code to be no more than around 60 columns. So what do we
learn? That attempts to generalise from personal anecdote doesn't get us
anywhere useful.

-- 
 \        “I took a course in speed waiting. Now I can wait an hour in |
  `\                                 only ten minutes.” —Steven Wright |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#71587

On Wed, 14 May 2014 19:36:13 -0700, Rustom Mody wrote:

> And there are (semi)hard technological limits like if you post code
> longer 65 chars out here it will fold at random unforeseen points. These
> limits get irrelevant as the technology changes.

The technological limits may become irrelevant, but the human limits do 
not. While there are no *hard* limits to readability, both excessively 
long and excessively short lines are hard to read. Comprehension and 
reading speed suffers.


> If any of these has any relation with the magic number '79' I'd be
> curious to know.

79 is one short of 80, which gives you a margin of error of 1: off-by-one 
errors won't matter if you aim for 79 characters but miscalculate by one.

People repeatedly state that 80 is the old, obsolete hard limit for 
ancient terminal systems, but the reason terminals standardised on 80 
rather than 70 or 90 (or for that matter 300 or 30) is at least in part 
-- and I maintain a big part -- because of human reading. 60 to 90 
characters per line is a comfortable range for human readability, which 
makes 80 a reasonable compromise that tends towards the upper end but 
without pushing hard up against it.

Keeping the monitor size and character size fixed, it's easy to show 
*fewer* characters per line if you choose a standard towards the upper 
end, if you so choose, but impossible to squeeze in more if you choose a 
standard at the lower end.

Just because the monitor (or the standard) *allows* up to 79 characters 
per line doesn't make it a good idea to regularly use that many. In my 
experience, given two or three indent levels, reasonably descriptive 
variable names, decently expressive expressions, I find that 60-70 
characters is *typically* enough horizontal space for the average line of 
code. Long lines are often (not always) a sign that you're doing too much 
in one line. This isn't Perl, and newlines are a renewable resource.


> Until then may we relegate '79' to quaint historical curiosities like:
> Continuation in 6th column, Comment is a C in 1st column, 7-72 for code
> (ALONG WITH ALL CAPS CODE)?

Nope. Because the main driving force for 79 characters is not technology 
but human reading.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#71631

On 15 May 2014 03:28:17 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following:


>Nope. Because the main driving force for 79 characters is not technology 
>but human reading.

	And even that is on the high side... publishing industry rule of thumb
is 2-2.5 "alphabets" (lower case, not both upper&lower) per line... Adjust
font size and margins to reach that.

http://practicaltypography.com/line-length.html
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#71588

On 15/05/2014 03:43, Ben Finney wrote:
> Rustom Mody <rustompmody@gmail.com> writes:
>
>> Until then may we relegate '79' to quaint historical curiosities
>
> Not until the general capacity of human cognition advances to make
> longer lines easier to read.
>
> We humans may be historical curiosities some day; until then, let's
> continue to write our code as though humans are the ones who will be
> reading it.
>

I thought code was meant to be read by programmers, not humans :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#71477

In article <mailman.9945.1399965443.18130.python-list@python.org>,
 Ganesh Pal <ganesh1pal@gmail.com> wrote:

> Hi  Team ,
> 
> 
> what would be the best way to intent the below line .
> 
> I have few lines in my program exceeding the allowed maximum line Length of
> 79./80 characters
> 
> Example 1 :
> 
>    p = Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)

The problem here is not so much that you've exceeded 80 columns, but that there's no logical
structure which gives your eyes (and your brain) hints about how to parse this.  I would
start by adding some white space

>    p = Subprocess.Popen(shlex.split(cmd), stdout=subprocess.PIPE, stderr=subprocess.PIPE)

now, at least, it's easier to see where each argument stops and the next one starts.  But,
I would really break this up into multiple lines

>    p = Subprocess.Popen(shlex.split(cmd),
>                         stdout=subprocess.PIPE,
>                         stderr=subprocess.PIPE)

[toc] | [prev] | [next] | [standalone]

#71479

Roy Smith <roy@panix.com> writes:

> >    p = Subprocess.Popen(shlex.split(cmd),
> >                         stdout=subprocess.PIPE,
> >                         stderr=subprocess.PIPE)

That is PEP 8 conformant, but I find it hurts maintainability: it is far
too much indentation. Horizontal space is costly, because so much
indentation severely limits the length of names etc. that you can use on
the continuation lines.

Worse, it is also needlessly tying all the continuation lines to the
length of the text before the open paren. What if ‘p’ changes to some
other name?

With the style I've advocated::

    p = Subprocess.Popen(
            shlex.split(cmd),
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE)

Changing the name on the first line doesn't entail changing any other
line::

    proc = Subprocess.Popen(
            shlex.split(cmd),
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE)

    special_process_map[this_process] = Subprocess.Popen(
            shlex.split(cmd),
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE)

Whereas with your suggestion, every line would need to change simply
because the first one did::


    special_process_map[this_process] = Subprocess.Popen(shlex.split(cmd),
                                                         stdout=subprocess.PIPE,
                                                         stderr=subprocess.PIPE)

Yes, that's contrived. But I prefer to use a style that doesn't need to
deal with the issue of when the indentation has gone too far for a
single statement.

It's for both those reasons that I recommend avoiding the “align with
open bracket” style, and instead use a standard eight-column indentation
for continuation lines.

-- 
 \          “One bad programmer can easily create two new jobs a year. |
  `\      Hiring more bad programmers will just increase our perceived |
_o__)                     need for them.” —David Lorge Parnas, 1999-03 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#71522

In article <mailman.9961.1399984013.18130.python-list@python.org>,
 Ben Finney <ben@benfinney.id.au> wrote:

> Roy Smith <roy@panix.com> writes:
> 
> > >    p = Subprocess.Popen(shlex.split(cmd),
> > >                         stdout=subprocess.PIPE,
> > >                         stderr=subprocess.PIPE)
> 
> That is PEP 8 conformant, but I find it hurts maintainability: it is far
> too much indentation. Horizontal space is costly, because so much
> indentation severely limits the length of names etc. that you can use on
> the continuation lines.

It only does that if you limit yourself to 80 character lines.

[toc] | [prev] | [next] | [standalone]

#71480

On 2014-05-13 22:26, Ben Finney wrote:
> Changing the name on the first line doesn't entail changing any
> other line::
> 
>     proc = Subprocess.Popen(
>             shlex.split(cmd),
>             stdout=subprocess.PIPE,
>             stderr=subprocess.PIPE)
> 
>     special_process_map[this_process] = Subprocess.Popen(
>             shlex.split(cmd),
>             stdout=subprocess.PIPE,
>             stderr=subprocess.PIPE)

I second the idea of just putting each-of-many-parameters on its own
line.  Not only that, I also like to tack on trailing commas and put
the closing paren on its own line to make diffs easier to read:

    special_process_map[this_process] = Subprocess.Popen(
        shlex.split(cmd),
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE,
        )

so that when I add the inevitable parameter, the diff merely reads
like

  --- tim1.txt    2014-05-13 07:44:42.441754319 -0500
  +++ tim2.txt    2014-05-13 07:45:35.753755858 -0500
  @@ -2,4 +2,5 @@
           shlex.split(cmd),
           stdout=subprocess.PIPE,
           stderr=subprocess.PIPE,
  +        bufsize=1024,
          )

which is quite clear that just one line was added, compared to

  --- ben1.txt    2014-05-13 07:44:51.033754566 -0500
  +++ ben2.txt    2014-05-13 07:45:46.737756176 -0500
  @@ -1,4 +1,5 @@
       special_process_map[this_process] = Subprocess.Popen(
           shlex.split(cmd),
           stdout=subprocess.PIPE,
  -        stderr=subprocess.PIPE)
  +        stderr=subprocess.PIPE,
  +        bufsize=1024)

which makes me have to think/verify about whether anything else
changed between insertion and deletion of lines.

-tkc

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web