Re: PEP8 79 char max

Discussion in 'Python' started by Devyn Collier Johnson, Jul 29, 2013.

  1. On 07/29/2013 04:08 PM, Joel Goldstick wrote:
    > On Mon, Jul 29, 2013 at 3:43 PM, Devyn Collier Johnson
    > <> wrote:
    >> In Python programming, the PEP8 recommends limiting lines to a maximum of 79
    >> characters because "There are still many devices around that are limited to
    >> 80 character lines" (http://www.python.org/dev/peps/pep-0008/#code-lay-out).
    >> What devices cannot handle 80 or more characters on a line?

    > well, punch cards ;)
    > Would following
    >> this recommendation improve script performance?

    > Not performance, but human readability
    >> Mahalo,
    >>
    >> Devyn Collier Johnson
    >>
    >> --
    >> http://mail.python.org/mailman/listinfo/python-list

    >
    >

    So, I can have a script with large lines and not negatively influence
    performance on systems that do not use punch cards?

    DCJ
     
    Devyn Collier Johnson, Jul 29, 2013
    #1
    1. Advertisements

  2. On Mon, 29 Jul 2013 16:24:51 -0400, Devyn Collier Johnson wrote:

    > So, I can have a script with large lines and not negatively influence
    > performance on systems that do not use punch cards?


    You'll negatively influence anyone who has to read, or edit, your code.
    Very likely including you.

    But no, there's no meaningful performance difference based on line
    length. Interpreting the source code is not meaningfully affected by line
    length, and by the time the code is compiled and then run, line length is
    irrelevant.



    --
    Steven
     
    Steven D'Aprano, Jul 29, 2013
    #2
    1. Advertisements

  3. On 07/29/2013 05:42 PM, Steven D'Aprano wrote:
    > On Mon, 29 Jul 2013 16:24:51 -0400, Devyn Collier Johnson wrote:
    >
    >> So, I can have a script with large lines and not negatively influence
    >> performance on systems that do not use punch cards?

    > You'll negatively influence anyone who has to read, or edit, your code.
    > Very likely including you.
    >
    > But no, there's no meaningful performance difference based on line
    > length. Interpreting the source code is not meaningfully affected by line
    > length, and by the time the code is compiled and then run, line length is
    > irrelevant.
    >
    >
    >

    Evidently, it is personal preference. I prefer to read computer code
    like a book (yes, I am a weirdo (^u^)). The only time I exced 79
    characters is when I write a set of commands that perform similar tasks.
    I do not make too many lines over 79 char. Thanks everyone for the
    comments and feedback.

    Mahalo,

    DCJ
     
    Devyn Collier Johnson, Jul 29, 2013
    #3
  4. Devyn Collier Johnson

    Ed Leafe Guest

    On Jul 29, 2013, at 5:30 PM, Devyn Collier Johnson <> wrote:

    > Evidently, it is personal preference. I prefer to read computer code like a book (yes, I am a weirdo (^u^)). The only time I exced 79 characters is when I write a set of commands that perform similar tasks. I do not make too many lines over 79 char. Thanks everyone for the comments and feedback.


    I have heard this statement before, and so I'm wondering: do you read books printed in monospaced typefaces, or do they have proportional fonts? I've yet to come across anything meant to be read as literature that was monospaced, because it is much harder to read.

    I had read about a developer who switched to using proportional fonts for coding, and somewhat skeptically, tried it out. After a day or so it stopped looking strange, and after a week it seemed so much easier to read. I only switched back because I found I lost productivity switching from vim to a graphical text editor.


    -- Ed Leafe
     
    Ed Leafe, Jul 29, 2013
    #4
  5. Ed Leafe wrote:

    > I had read about a developer who switched to using proportional fonts for
    > coding, and somewhat skeptically, tried it out. After a day or so it
    > stopped looking strange, and after a week it seemed so much easier to
    > read.


    By my (limited) experience with proportional fonts, they can be useful only
    with something like elastic tabstops[0]. But, as a general rule, I simply
    found more "squared" to just use a fixed-width font.


    [0] http://nickgravgaard.com/elastictabstops/

    --
    ZeD
     
    Vito De Tullio, Jul 30, 2013
    #5
  6. On 30 July 2013 18:08, Vito De Tullio <> wrote:

    > Ed Leafe wrote:
    >
    > > I had read about a developer who switched to using proportional fonts for
    > > coding, and somewhat skeptically, tried it out. After a day or so it
    > > stopped looking strange, and after a week it seemed so much easier to
    > > read.

    >
    > By my (limited) experience with proportional fonts, they can be useful only
    > with something like elastic tabstops[0]. But, as a general rule, I simply
    > found more "squared" to just use a fixed-width font.
    >


    Not if you give up on the whole "aligning" thing.


    > [0] http://nickgravgaard.com/elastictabstops/
    >
     
    Joshua Landau, Jul 30, 2013
    #6
  7. On 2013-07-30, Joshua Landau <> wrote:
    > On 30 July 2013 18:08, Vito De Tullio <> wrote:
    >
    >> Ed Leafe wrote:
    >>
    >> > I had read about a developer who switched to using proportional fonts for
    >> > coding, and somewhat skeptically, tried it out. After a day or so it
    >> > stopped looking strange, and after a week it seemed so much easier to
    >> > read.

    >>
    >> By my (limited) experience with proportional fonts, they can be useful only
    >> with something like elastic tabstops[0]. But, as a general rule, I simply
    >> found more "squared" to just use a fixed-width font.
    >>

    >
    > Not if you give up on the whole "aligning" thing.


    You don't think that Python code at a given level should all be
    aligned? I find it very helpful when a given block of code is
    visually left-aligned.

    I also find intializers for tables of data to be much more easily read
    and maintained if the columns can be aligned.

    --
    Grant Edwards grant.b.edwards Yow! MMM-MM!! So THIS is
    at BIO-NEBULATION!
    gmail.com
     
    Grant Edwards, Jul 30, 2013
    #7
  8. Joshua Landau wrote:

    >> By my (limited) experience with proportional fonts, they can be useful
    >> only with something like elastic tabstops[0]. But, as a general rule, I
    >> simply found more "squared" to just use a fixed-width font.


    > Not if you give up on the whole "aligning" thing.



    and this is one of the reason why I come back to fixed-width

    --
    By ZeD
     
    Vito De Tullio, Jul 30, 2013
    #8
  9. On 30 July 2013 18:52, Grant Edwards <> wrote:

    > On 2013-07-30, Joshua Landau <> wrote:
    > > On 30 July 2013 18:08, Vito De Tullio <> wrote:
    > >
    > >> Ed Leafe wrote:
    > >>
    > >> > I had read about a developer who switched to using proportional fonts

    > for
    > >> > coding, and somewhat skeptically, tried it out. After a day or so it
    > >> > stopped looking strange, and after a week it seemed so much easier to
    > >> > read.
    > >>
    > >> By my (limited) experience with proportional fonts, they can be useful

    > only
    > >> with something like elastic tabstops[0]. But, as a general rule, I

    > simply
    > >> found more "squared" to just use a fixed-width font.
    > >>

    > >
    > > Not if you give up on the whole "aligning" thing.

    >
    > You don't think that Python code at a given level should all be
    > aligned? I find it very helpful when a given block of code is
    > visually left-aligned.
    >


    I don't understand what you mean. My coding practices almost never require
    anything more than the initial indentation to have things line up -- any
    other form of alignment is in my opinion overrated. Maybe it helps you, but
    personally I don't like it.

    As I've been saying, the whole thing is personal preference and
    proportional fonts for some people, such as I, are fine. Except in that
    there are no good proportional fonts at 8px :(.

    To explain, I tend to take the "HTML" form of alignment by wrapping:

    open stuff stuff stuff close

    to

    open
    stuff
    stuff
    stuff
    close

    and thus everything important lines up anyway. Extra non-indentation
    indents are a burden for me and look worse (again, personal preference).

    I also find intializers for tables of data to be much more easily read
    > and maintained if the columns can be aligned.
    >


    Why do you have tables in your Python code?
     
    Joshua Landau, Jul 31, 2013
    #9
  10. Devyn Collier Johnson

    Tim Chase Guest

    On 2013-07-31 07:16, Joshua Landau wrote:
    > On 30 July 2013 18:52, Grant Edwards wrote:
    >> I also find intializers for tables of data to be much more easily
    >> read and maintained if the columns can be aligned.

    >
    > Why do you have tables in your Python code?


    I've had occasion to write things like:

    for name, value, description in (
    ("cost", 42, "How much it cost"),
    ("status", 3141, "Status code from ISO-3.14159"),
    ...
    ):
    do_something(name, value)
    print(description)

    I interpret Grant's statement as wanting the "table" to look like

    for name, value, description in (
    ("cost", 42, "How much it cost"),
    ("status", 3141, "Status code from ISO-3.14159"),
    ...
    ):
    do_something(name, value)
    print(description)

    which does give some modest readability benefits, but at a creation
    cost I personally am unwilling to pay.

    -tkc
     
    Tim Chase, Jul 31, 2013
    #10
  11. Devyn Collier Johnson

    Neil Cerutti Guest

    On 2013-07-31, Tim Chase <> wrote:
    > On 2013-07-31 07:16, Joshua Landau wrote:
    >> On 30 July 2013 18:52, Grant Edwards wrote:
    >>> I also find intializers for tables of data to be much more easily
    >>> read and maintained if the columns can be aligned.

    >>
    >> Why do you have tables in your Python code?

    >
    > I've had occasion to write things like:
    >
    > for name, value, description in (
    > ("cost", 42, "How much it cost"),
    > ("status", 3141, "Status code from ISO-3.14159"),
    > ...
    > ):
    > do_something(name, value)
    > print(description)
    >
    > I interpret Grant's statement as wanting the "table" to look like
    >
    > for name, value, description in (
    > ("cost", 42, "How much it cost"),
    > ("status", 3141, "Status code from ISO-3.14159"),
    > ...
    > ):
    > do_something(name, value)
    > print(description)
    >
    > which does give some modest readability benefits, but at a
    > creation cost I personally am unwilling to pay.


    I'm actually OK with the creation cost, but not the maintenance cost.

    --
    Neil Cerutti
     
    Neil Cerutti, Jul 31, 2013
    #11
  12. On 2013-07-31, Tim Chase <> wrote:
    > On 2013-07-31 07:16, Joshua Landau wrote:
    >> On 30 July 2013 18:52, Grant Edwards wrote:
    >>> I also find intializers for tables of data to be much more easily
    >>> read and maintained if the columns can be aligned.

    >>
    >> Why do you have tables in your Python code?


    For example: if you're writing an assembler, you usually have a table
    of mnemonics/opcodes/instruction-format/addressing-modes.

    > I've had occasion to write things like:
    >
    > for name, value, description in (
    > ("cost", 42, "How much it cost"),
    > ("status", 3141, "Status code from ISO-3.14159"),
    > ...
    > ):
    > do_something(name, value)
    > print(description)
    >
    > I interpret Grant's statement as wanting the "table" to look like
    >
    > for name, value, description in (
    > ("cost", 42, "How much it cost"),
    > ("status", 3141, "Status code from ISO-3.14159"),
    > ...
    > ):
    > do_something(name, value)
    > print(description)


    Exactly. When you have more than about 5 columns and 10 rows, having
    things aligned makes it far, far, easier to maintain.

    > which does give some modest readability benefits, but at a creation
    > cost I personally am unwilling to pay.


    It only gets typed once, it gets read hundreds or thousands of times.
    Optimize the common case.

    --
    Grant Edwards grant.b.edwards Yow! I am NOT a nut....
    at
    gmail.com
     
    Grant Edwards, Jul 31, 2013
    #12
  13. On 2013-07-31, Neil Cerutti <> wrote:
    > On 2013-07-31, Tim Chase <> wrote:
    >> On 2013-07-31 07:16, Joshua Landau wrote:
    >>> On 30 July 2013 18:52, Grant Edwards wrote:
    >>>> I also find intializers for tables of data to be much more easily
    >>>> read and maintained if the columns can be aligned.
    >>>
    >>> Why do you have tables in your Python code?

    >>
    >> I've had occasion to write things like:
    >>
    >> for name, value, description in (
    >> ("cost", 42, "How much it cost"),
    >> ("status", 3141, "Status code from ISO-3.14159"),
    >> ...
    >> ):
    >> do_something(name, value)
    >> print(description)
    >>
    >> I interpret Grant's statement as wanting the "table" to look like
    >>
    >> for name, value, description in (
    >> ("cost", 42, "How much it cost"),
    >> ("status", 3141, "Status code from ISO-3.14159"),
    >> ...
    >> ):
    >> do_something(name, value)
    >> print(description)
    >>
    >> which does give some modest readability benefits, but at a
    >> creation cost I personally am unwilling to pay.

    >
    > I'm actually OK with the creation cost, but not the maintenance cost.


    In my experience, aligning columns in large tables reduces maintence
    cost by making it much easier/faster to see what you've got and by
    providing a way to visually "prompt" you for the correct value in the
    correct place when you add new lines.

    --
    Grant Edwards grant.b.edwards Yow! hubub, hubub, HUBUB,
    at hubub, hubub, hubub, HUBUB,
    gmail.com hubub, hubub, hubub.
     
    Grant Edwards, Jul 31, 2013
    #13
  14. Devyn Collier Johnson

    Marcelo MD Guest

    >
    > In my experience, aligning columns in large tables reduces maintence
    > cost by making it much easier/faster to see what you've got and by
    > providing a way to visually "prompt" you for the correct value in the
    > correct place when you add new lines.
    >
    >

    Works great until one of the values changes in size. Say:
    bla = (
    .....1.0, 1.1, 1.2,
    .....2.0, 2.1, 2.2,
    .....3.0, 2.1, 3.2,
    )

    And one day you have to change '2.1' to '2.09999':
    bla = (
    .....1.0, 1.1, 1.2,
    .....2.0, 2.09999, 2.2,
    .....3.0, 2.1, 3.2,
    )

    If this happens more than once ( or twice, because I'm patient =)),
    maintaining the alignment becomes a chore. So I only align columns if I'm
    typing a table I know won't change.


    --
    Marcelo Mallmann Dias
     
    Marcelo MD, Jul 31, 2013
    #14
  15. Devyn Collier Johnson

    Neil Cerutti Guest

    On 2013-07-31, Marcelo MD <> wrote:
    >> In my experience, aligning columns in large tables reduces
    >> maintence cost by making it much easier/faster to see what
    >> you've got and by providing a way to visually "prompt" you for
    >> the correct value in the correct place when you add new lines.

    >
    > Works great until one of the values changes in size. Say:
    > bla = (
    > ....1.0, 1.1, 1.2,
    > ....2.0, 2.1, 2.2,
    > ....3.0, 2.1, 3.2,
    > )
    >
    > And one day you have to change '2.1' to '2.09999':
    > bla = (
    > ....1.0, 1.1, 1.2,
    > ....2.0, 2.09999, 2.2,
    > ....3.0, 2.1, 3.2,
    > )
    >
    > If this happens more than once ( or twice, because I'm patient =)),
    > maintaining the alignment becomes a chore. So I only align columns if I'm
    > typing a table I know won't change.


    Yes, that was my exprience, too.

    Besides, after studying The Pragmatic Programmer I removed nearly
    all the tables from my code and reference them (usually with csv
    module) instead.

    --
    Neil Cerutti
     
    Neil Cerutti, Jul 31, 2013
    #15
  16. => Works great until one of the values changes in size.

    Slightly off-topic, but still sort of related (talking about the size
    of things), I started picking 1e+30 as my "really big" some time back
    because the repr of 1e+99 required more than a glance when it appeared
    in printed output:

    >>> repr(1e+30)

    '1e+30'
    >>> repr(1e+99)

    '9.9999999999999997e+98'

    This problem was fixed in 2.7 (and presumably in 3.something as well),
    but it used to be a problem. :)

    Skip
     
    Skip Montanaro, Jul 31, 2013
    #16
  17. On 2013-07-31, Neil Cerutti <> wrote:

    > Besides, after studying The Pragmatic Programmer I removed nearly
    > all the tables from my code and reference them (usually with csv
    > module) instead.


    I don't understand. That just moves them to a different file --
    doesn't it? You've still got to deal with editing a large table of
    data (for example when I want to add instructions to your assembler).

    --
    Grant Edwards grant.b.edwards Yow! Spreading peanut
    at butter reminds me of
    gmail.com opera!! I wonder why?
     
    Grant Edwards, Jul 31, 2013
    #17
  18. Devyn Collier Johnson

    Tim Chase Guest

    On 2013-07-31 16:32, Grant Edwards wrote:
    > On 2013-07-31, Tim Chase <> wrote:
    > > I interpret Grant's statement as wanting the "table" to look like
    > >
    > > for name, value, description in (
    > > ("cost", 42, "How much it cost"),
    > > ("status", 3141, "Status code from ISO-3.14159"),
    > > ...
    > > ):
    > > do_something(name, value)
    > > print(description)

    >
    > Exactly. When you have more than about 5 columns and 10 rows,
    > having things aligned makes it far, far, easier to maintain.


    As mentioned by Marcelo, when they can vary in length, maintaining is
    a pain. Even if your editor supports aligning (like vim with Dr.
    Chip's align.vim plugin). If I have a table of greater dimensions, I
    tend to refactor into a more readable+maintainable scheme, whether
    using dicts or named tuples and then break out the rows onto their own
    lines:

    from collections import namedtuple
    Descriptor = namedtuple("Descriptor", ["name", "value",
    "description"])
    for name, value, description in (
    Descriptor(
    name="cost",
    value=42,
    description="How much it cost",
    ),
    Descriptor(
    name="status",
    value=3141,
    description="Status code from ISO-3.14159",
    ),
    ):
    do_something(name, value)
    print(description)

    Using a namedtuple, if you forget one of the fields (or add an
    extra, or misspell one), it yells at you:

    TypeError: __new__() takes exactly 4 arguments (2 given)
    TypeError: __new__() takes exactly 4 arguments (6 given)
    TypeError: __new__() got an unexpected keyword argument 'nmae'

    There is redundancy of the kwarg params, but this can be skipped
    if you prefer DRY code to more readable code.

    Doing this also has the benefit that, when diffing, you don't get
    noise when columns are merely adjusted visually.

    -tkc
     
    Tim Chase, Jul 31, 2013
    #18
  19. Devyn Collier Johnson

    Tim Chase Guest

    On 2013-07-31 16:32, Grant Edwards wrote:
    > On 2013-07-31, Tim Chase <> wrote:
    > > I interpret Grant's statement as wanting the "table" to look like
    > >
    > > for name, value, description in (
    > > ("cost", 42, "How much it cost"),
    > > ("status", 3141, "Status code from ISO-3.14159"),
    > > ...
    > > ):
    > > do_something(name, value)
    > > print(description)

    >
    > Exactly. When you have more than about 5 columns and 10 rows,
    > having things aligned makes it far, far, easier to maintain.


    As mentioned by Marcelo, when they can vary in length, maintaining is
    a pain. Even if your editor supports aligning (like vim with Dr.
    Chip's align.vim plugin). If I have a table of greater dimensions, I
    tend to refactor into a more readable+maintainable scheme, whether
    using dicts or named tuples and then break out the rows onto their own
    lines:

    from collections import namedtuple
    Descriptor = namedtuple("Descriptor", ["name", "value", "description"])
    for name, value, description in (
    Descriptor(
    name="cost",
    value=42,
    description="How much it cost",
    ),
    Descriptor(
    name="status",
    value=3141,
    description="Status code from ISO-3.14159",
    ),
    ):
    do_something(name, value)
    print(description)

    Using a namedtuple, if you forget one of the fields (or add an
    extra, or misspell one), it yells at you:

    TypeError: __new__() takes exactly 4 arguments (2 given)
    TypeError: __new__() takes exactly 4 arguments (6 given)
    TypeError: __new__() got an unexpected keyword argument 'nmae'

    There is redundancy of the kwarg params, but this can be skipped
    if you prefer DRY code to more readable code.

    Doing this also has the benefit that, when diffing, you don't get
    noise when columns are merely adjusted visually.

    -tkc
     
    Tim Chase, Jul 31, 2013
    #19
  20. Grant Edwards wrote:
    > On 2013-07-31, Neil Cerutti <> wrote:
    >
    > > Besides, after studying The Pragmatic Programmer I removed nearly
    > > all the tables from my code and reference them (usually with csv
    > > module) instead.

    >
    > I don't understand. That just moves them to a different file --
    > doesn't it? You've still got to deal with editing a large table of
    > data (for example when I want to add instructions to your assembler).
    >
    > --
    > Grant Edwards grant.b.edwards Yow! Spreading peanut
    > at butter reminds me of
    > gmail.com opera!! I wonder why?
    > --


    True, but a CSV file is easy to edit in something like a spreadsheet
    application (LibreOffice/MS Office); alignment becomes automatic
    then.


    Ramit





    This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy andcompleteness of information, viruses, confidentiality, legal privilege, andlegal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
     
    Prasad, Ramit, Jul 31, 2013
    #20
    1. Advertisements

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Devyn Collier Johnson

    PEP8 79 char max

    Devyn Collier Johnson, Jul 29, 2013, in forum: Python
    Replies:
    3
    Views:
    179
    llanitedave
    Jul 31, 2013
  2. Joel Goldstick

    Re: PEP8 79 char max

    Joel Goldstick, Jul 29, 2013, in forum: Python
    Replies:
    0
    Views:
    158
    Joel Goldstick
    Jul 29, 2013
  3. Ed Leafe

    Re: PEP8 79 char max

    Ed Leafe, Jul 29, 2013, in forum: Python
    Replies:
    2
    Views:
    161
    Joshua Landau
    Jul 29, 2013
  4. Terry Reedy

    Re: PEP8 79 char max

    Terry Reedy, Jul 29, 2013, in forum: Python
    Replies:
    0
    Views:
    131
    Terry Reedy
    Jul 29, 2013
  5. Skip Montanaro

    Re: PEP8 79 char max

    Skip Montanaro, Jul 29, 2013, in forum: Python
    Replies:
    0
    Views:
    138
    Skip Montanaro
    Jul 29, 2013
Loading...

Share This Page