PEP 8 : Maximum line Length :

[Rustom Mody]

Johannes Bauer :




Well, if I have to work with your code, you are forcing your style on
me.




That's a good point: why aren't we just exchanging AST's and configuring
the editor to display them in our preferred format?

Well, we're not there yet.

Yes, regarding programmers using plain-text instead of hypertext
at http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html

I wrote:

And yet programmers continue to be decades behind all other users of computers. We continue to use flat text for our programs when all others have moved on.

 

[Roy Smith]

And yet programmers continue to be decades behind all other users of
computers. We continue to use flat text for our programs when all others
have moved on.

It's not like we haven't tried. There have been a few attempts at using
richer media to program (graphical UML editors, for example). They've
all pretty much been failures.

There *are* some places where non-text programming has won. The biggest
example would be GUI builders. Nobody programs screen and window
layouts by typing textual descriptions. They push boxes around in a GUI
builder.

 

[Rustom Mody]

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

 

[Marko Rauhamaa]

We continue to use flat text for our programs when all others have
moved on.

My more moderate and immediate point is, why should the physical
encoding of the program be also the presentation format?

A definitive Python source file could be binary, XML, .py, .ast,
whatever, and that would also be the file fed to the Python
compiler/interpreter. However, your editor could choose freely how to
present it to you.

IOW, shouldn't PEP8 be redundant?


Marko

 

[Chris Angelico]

There *are* some places where non-text programming has won. The biggest
example would be GUI builders. Nobody programs screen and window
layouts by typing textual descriptions. They push boxes around in a GUI
builder.

Hi, I'm Nobody, and I like warm hugs!

My GUI building is entirely by typing textual descriptions. Yes, there
are some good builders, but I do my layouts on a basis of rules rather
than strict pixel positions. Rules and bag-based layouts mean there's
no problem with something getting too big and messing up your layout.

Is it really helpful to drag objects into a nearly-invisible "Vertical
Box" container? Pushing boxes around is great when you attach
everything directly to the window, but that gets messed up pretty
quickly by a user's themes, font sizes, etc (not to mention a change
of platform). Explicitly putting things into their boxes, grids,
tables, etc means it's always right.

ChrisA

 

[Rustom Mody]

Rustom Mody wrote:






It's not like we haven't tried. There have been a few attempts at using
richer media to program (graphical UML editors, for example). They've
all pretty much been failures.

In Fifth Discipline, Peter Senge starts by dilating on the length of time between
1903 when the Wright brothers first flew and 1935 when the DC-3 ushered in commercial air travel.

Five things were needed for that transition from pioneering to commercial:

| They were: the variable-pitch propeller, retractable landing gear, a type of
| lightweight molded body construction called "monocque," radial air-cooled
| engine, and wing flaps. To succeed, the DC-3 needed all five; four were not
| enough. One year earlier, the Boeing 247 was introduced with all of them except
| wing flaps. Lacking wing flaps, Boeing's engineers found that the plane was
| unstable on take-off and landing and had to downsize the engine.

So maybe you are just being pessimistic when in fact we are in the (equivalent of)
that 30 year period?

Two more examples:
Dijkstra pointed out that it typically takes an idea a hundred years from discovery
to mainstream. Think Cantor inventing set theory in 1880s, modern math entering
schools in 1970s.

A more extreme example: Europeans learnt first of Hindu-Arabic numerals in around
1000 AD. IT took a good 500 years to give up on Roman numerals

There *are* some places where non-text programming has won. The biggest
example would be GUI builders. Nobody programs screen and window
layouts by typing textual descriptions. They push boxes around in a GUI
builder.

And yet you routinely find people on this list recommending writing python to using
a GUI-builder.
On the one hand I am tempted to say "Sheesh!!"
On the other, maybe the builders are still too half-assed... Dunno

[BTW is there any equivalent for html?]

 

[Chris Angelico]

A definitive Python source file could be binary, XML, .py, .ast,
whatever, and that would also be the file fed to the Python
compiler/interpreter. However, your editor could choose freely how to
present it to you.

IOW, shouldn't PEP8 be redundant?

I believe the Python interpreter happily accepts a zip file, which in
theory could be edited directly by a competent text editor. But that
has nothing to do with PEP 8. Compare a classic compiled language like
C - you have the bit you edit (the C source code) and the "definitive
version" that's fed to the program loader (the compiled binary). Style
guides apply to the edited version, not to the executed version.

ChrisA

 

[Marko Rauhamaa]

And yet you routinely find people on this list recommending writing
python to using a GUI-builder. On the one hand I am tempted to say
"Sheesh!!" On the other, maybe the builders are still too
half-assed... Dunno

That's like diagnosing cancer without invasive procedures, lab tests and
interviews: the doctor should be able to look at how pale you look and
if your skin has any funny bulges.

Thing is, programs and even text documents and spreadsheets have a lot
more abstract structure, dynamics and dependencies than the visible
façade. Block diagrams and graphics can be great presentation tools, but
nothing beats text in concise, explicit expressiveness.

An everyday example: a word processor displays the word "hello" with
"hel" in boldface and "lo" in italics. You put the cursor between the
l's and type a letter. Should it be in boldface or italics?

Who of you hasn't sworn at a Web editor that gets the formatting all
messed up when you have typed a backspace in the "wrong place?"


Marko

 

[Marko Rauhamaa]

I believe the Python interpreter happily accepts a zip file, which in
theory could be edited directly by a competent text editor. But that
has nothing to do with PEP 8. Compare a classic compiled language like
C - you have the bit you edit (the C source code) and the "definitive
version" that's fed to the program loader (the compiled binary). Style
guides apply to the edited version, not to the executed version.

My point applies to C as well. Shouldn't the .c file contain an AST?
Only when you open the file in your text editor, it makes it look like
you wrote it yourself in your favorite style?

You and I could have opened the same C file. Only you see:

#include <stdio.h>

int +--------------------+
main ( int argc, | My first C program |
char *const argv[] ) +--------------------+
{
(void) printf( "Hello world\n" );

return(0);
}

while I see:

#include <stdio.h>

/* My first C program */
int main(int argc, char *const argv[]) {
printf("Hello world\n");
return 0;
}


Marko

 

[Skip Montanaro]

Who of you hasn't sworn at a Web editor that gets the formatting all
messed up when you have typed a backspace in the "wrong place?"

My current pet peeve is the Gmail composition pane. What a load of
crap (especially in rich text mode).

You set the font to Sans Serif, start typing. Everything is in
Courier. Select All, switch everything to Sans Serif, and it redraw
the text, still in Courier, but in a different version of Courier.
Switch back to plain text mode. It has not-too-helpfully inserted line
breaks everywhere the rich text editor surrounded text with <div>
tags. Go back and delete all of them. Edit your text. Proofread your
text. Switch back to rich text so you can insert the image you wanted
to display. Hit Send.

Haven't we had WYSIWYG editors for about 40 years?

Skip

 

[Chris Angelico]

An everyday example: a word processor displays the word "hello" with
"hel" in boldface and "lo" in italics. You put the cursor between the
l's and type a letter. Should it be in boldface or italics?

Impossible to say, and one of the perpetual annoyances. Here's a web
site that I host:

http://gilbertandsullivan.org.au/in...92:2001-patience&catid=30:patience&Itemid=102

(Tiny URL: http://tinyurl.com/pphpkuk )

Why is "Lt Duke of Dunstable" different from all the other character
names? (By the way, I just picked an article at random from the
archive, and the first random pick had an example of what I'm talking
about. It's fairly prevalent on that site.) Now, if this were
hand-written HTML2, this sort of thing wouldn't happen; and, even
better, if the structure and formatting were properly separated (as in
my proposed web site redesign), they'd not only be guaranteed
consistent within a page, but also *across* pages.

Tagged text works well. In HTML pages, that means literal
<angle><bracket><tags>; in programming, that's all our various
notations and things. I wouldn't want to write code by writing a bunch
of words and then marking "This word is an assignment target, this one
is an object that you should find a method on, this one is the method
name, and these ones are the arguments". I want to put = . ( ) to mark
those. More efficient... MUCH more reliable. And, bonus: it's all
text.

ChrisA

 

[Chris Angelico]

You and I could have opened the same C file. Only you see:

#include <stdio.h>

int +--------------------+
main ( int argc, | My first C program |
char *const argv[] ) +--------------------+
{
(void) printf( "Hello world\n" );

return(0);
}

while I see:

#include <stdio.h>

/* My first C program */
int main(int argc, char *const argv[]) {
printf("Hello world\n");
return 0;
}

Well no, for two reasons. Firstly, I think the first one looks
disgusting, so even if I had that feature, I wouldn't use it like that


But more importantly: You can already do that sort of thing, and it's
a bad idea. Maybe there aren't any text editors that can do it, but
you can use source control that way. (I'm going to use git as my
example, as I don't know how it's done in hg or any other; but I'm
sure it won't be hard.) You just tell git that these files (probably
"files matching glob *.c") are to be reformatted, and provide two
commands: one that cleans a file prior to it going into source
control, and one that "smudges" it at the other end. So you could
simply write a code reformatter and register it as your smudge
command, and (in the interests of readable diffs) have some
standardized reformatter as the clean command. Voila! You now can
check out my code with your formatting.

Which brings me to the second reason for not doing this. That
clean/smudge operation *destroys information*. Once you enforce code
formatting like that, you violate PEP 8's "rule zero": sometimes, it's
better to break the rules. Sometimes, your nice code reformatting
operation will actually make the program worse... and there'll be no
way for you to get back from that.

Not to mention that any reformatting that inserts or deletes lines is
a pain for debugging. "Line 42" on your screen and "Line 42" in the
traceback won't be the same thing any more. If I run your code and
give you an exception trace, you'll have to check out my version of
the code to be able to understand anything. Theoretically that could
be solved (eg you absolutely always run the checked-in version - of
course, that assumes that everyone's smudge and clean will perfectly
recreate the exact same output), but even with editor support, where
you'd move the cursor around and the line number would go berserk
(press down-arrow three times and the line number goes 5, 6, 6, 10),
it would be a pain.

Code is a text file. So is music (I use GNU LilyPond, and everything
works like code). So is data, in many many cases. So is configuration,
often, although some programs prefer to work with an opaque format.
About the only thing that really definitely shouldn't be massaged into
text is actual 2D images. Can you turn this into a few lines of code?

https://lh3.googleusercontent.com/-_8upQkJcvjE/UhTJlDzW3ZI/AAAAAAAABU8/QvExuUq47dI/s512/DSCF7600.JPG

Pretty much everything else, though, works better as plain text.

ChrisA

 

[Mark Lawrence]

It's not like we haven't tried. There have been a few attempts at using
richer media to program (graphical UML editors, for example). They've
all pretty much been failures.

This http://sourceforge.net/projects/doublesvsoop/ was project of the
month just a little while ago, so it's obviously overcome all of the
known obstacles, in exactly the same way that all previous silver
bullets have done. At least I think it's the kind of thing that you're
talking about.

 

[Terry Reedy]

Impossible to say, and one of the perpetual annoyances. Here's a web
site that I host:

http://gilbertandsullivan.org.au/in...92:2001-patience&catid=30:patience&Itemid=102

(Tiny URL: http://tinyurl.com/pphpkuk )

Why is "Lt Duke of Dunstable" different from all the other character
names?

For me, Windows FF, it is not different that I can see.

 

[Terry Reedy]

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?

 

[MRAB]

For me, Windows FF, it is not different that I can see.

For me, with Firefox on Windows, it's slightly bolder, but that's
probably because its colour is specified, unlike the others.

 

[Rustom Mody]

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.

 

[Dennis Lee Bieber]

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

 

[Steven D'Aprano]

Well, if I have to work with your code, you are forcing your style on
me.
+1



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]

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.