PEP 8 : Maximum line Length :

Discussion in 'Python' started by Ganesh Pal, May 13, 2014.

  1. Ganesh Pal

    Rustom Mody Guest

    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.
     
    Rustom Mody, May 15, 2014
    #21
    1. Advertisements

  2. Ganesh Pal

    Roy Smith Guest

    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.
     
    Roy Smith, May 15, 2014
    #22
    1. Advertisements

  3. Ganesh Pal

    Rustom Mody Guest

    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
     
    Rustom Mody, May 15, 2014
    #23
  4. 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
     
    Marko Rauhamaa, May 15, 2014
    #24
  5. 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
     
    Chris Angelico, May 15, 2014
    #25
  6. Ganesh Pal

    Rustom Mody Guest

    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
    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?]
     
    Rustom Mody, May 15, 2014
    #26
  7. 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
     
    Chris Angelico, May 15, 2014
    #27
  8. 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, May 15, 2014
    #28
  9. 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
     
    Marko Rauhamaa, May 15, 2014
    #29
  10. 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
     
    Skip Montanaro, May 15, 2014
    #30
  11. 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, May 15, 2014
    #31
  12. 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
     
    Chris Angelico, May 15, 2014
    #32
  13. 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.
     
    Mark Lawrence, May 15, 2014
    #33
  14. Ganesh Pal

    Terry Reedy Guest

    Terry Reedy, May 15, 2014
    #34
  15. Ganesh Pal

    Terry Reedy Guest

    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 Reedy, May 15, 2014
    #35
  16. Ganesh Pal

    MRAB Guest

    For me, with Firefox on Windows, it's slightly bolder, but that's
    probably because its colour is specified, unlike the others.
     
    MRAB, May 16, 2014
    #36
  17. Ganesh Pal

    Rustom Mody Guest

    The claim being made is that 79/80 is a fundamental, cognitive limit and has
    no relation to technological changes.
     
    Rustom Mody, May 16, 2014
    #37
  18. 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
     
    Dennis Lee Bieber, May 16, 2014
    #38
  19. 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.

    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, May 16, 2014
    #39
  20. 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, May 16, 2014
    #40
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.