Re: A desperate lunge for on-topic-ness

Discussion in 'Python' started by Evan Driscoll, Oct 18, 2012.

  1. Ooo, a good religious war. How could I resist? :) Bear in mind that
    what I say is relative to layout issues, which in the grand scheme of
    things. So even if I say I really disklike something, it's still not so
    bad in practice. Except for backslash continuations. :)

    On 10/18/2012 01:06 AM, Zero Piraeus wrote:
    > What are people's preferred strategies for dealing with lines that go
    > over 79 characters?

    My general rules are:

    1. I dislike 80 character limits, and basically don't make a
    particularly strong attempt adhere to them for, well, basically
    any code I write, Python or not. I'll explain a little bit of why
    later. (I'd begrudgingly go along if I were working on a different
    code base that did of course, but in the meantime I don't have to
    deal with corporate style standards or anything like that so can
    bend the rules a bit.) 100 about where I start getting
    uncomfortable, and my semi-hard limit is 110-120. No doubt that's
    because that's about the line length I get with half of my monitor's
    width. :)

    Python isn't as bad as C++ though (my main other language), where
    80 characters can go by *very* quickly.

    2. Backslash continuations are *terrible*. I hate them with a firery
    passion. :) A line could be 1000 characters long and it would be
    better than a 120-character line backslash-continued.

    3. Using parentheses for continuations is sunshine and rainbows.

    4. Extra variables are also great; I suspect I tend to use a
    more-than-average amount of extra variables anyway. (Though
    probably less so compared with the Python coder community than with
    the C++ coder community.)

    Hans Mulder said:
    > Steven D'Aprano said:
    >> some_variable = spam('x') + ham(
    >> some_longer_variables, here_and_here,
    >> and_here_also)

    > I would spell that as:
    > some_variable = spam('x') + ham(
    > some_longer_variables,
    > here_and_here,
    > and_here_also,
    > )

    Ugh, I hate both. :) I really dislike the arguments to a function
    appearing to the left of the function. I'm fine with either




    but the two quoted suggestion makes me cringe a bit. (Of my two options,
    I think I actually prefer the latter, but tend to use the former because
    I'm too lazy to figure out how to make Emacs do the second one.)

    So with the above rule I might format that as:

    some_variable = spam('x') + ham(some_longer_variables,

    except that runs afoul of another of my implict formatting "rules",
    which is that if I have a multi-argument construct (e.g. an operator
    or function call) and one of the arguments is multiple lines, I'd prefer
    to see all of the arguments on their own lines. So I'd format
    that as:

    some_variable = (spam('x')
    + ham(a, b, c))

    as my first choice (long var names truncated here, but in real code with
    no indent that's only 76 characters with the full ones in so it's fine
    -- I'd do it that way even with a couple levels of indent) and

    some_variable = (spam('x')
    + ham(some_longer_variables,

    as my second, even though they require an extra set of parentheses and
    even though there is plenty of room on the first line for "foo +

    The reason I say I dislike the quoted suggestions -- and ultimately why
    I really dislike the 80 character limit -- is the following. If you ask
    proponents of the 80 character limit, they'll tell you about how there's
    only so much horizontal space and stuff like that. But I think that
    ignores the benefits you get from intelligently using *vertical* space,
    and I think the quoted suggestions do too.

    I've taken each of the suggested formattings of the above and turned
    them into a graphic, which you can see at

    I've drawn the boundary of every valid subexpression (except for the RHS
    of each assignment) in each of the versions. In my suggestions, the
    "ham(....)" subexpression is always contained within a rectangle -- in
    the quoted suggestions, it is not, and is a more complicated shape. It
    seems to me that the relationship between the vertical and horizontal
    layout in those examples is somewhat haphazard. I can't even come up
    with a "rule" for how the quoted examples arose; for mine, I'd say I'm
    trying to keep subexpressions together in space (both horizontal and
    vertical). I'm not sure that "drawing boxes" is exactly the right thing
    to say what I'm doing, but I think it at least serves to illustrate my
    point in this case.


    Version: GnuPG v2.0.14 (GNU/Linux)
    Comment: Using GnuPG with Mozilla -

    -----END PGP SIGNATURE-----
    Evan Driscoll, Oct 18, 2012
    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. Zero Piraeus

    A desperate lunge for on-topic-ness

    Zero Piraeus, Oct 18, 2012, in forum: Python
    Krzysztof Voss
    Oct 19, 2012
  2. Chris Angelico

    Re: A desperate lunge for on-topic-ness

    Chris Angelico, Oct 18, 2012, in forum: Python
    Chris Angelico
    Oct 18, 2012
  3. Demian Brecht

    Re: A desperate lunge for on-topic-ness

    Demian Brecht, Oct 18, 2012, in forum: Python
    Demian Brecht
    Oct 18, 2012
  4. Mark Lawrence

    Re: A desperate lunge for on-topic-ness

    Mark Lawrence, Oct 18, 2012, in forum: Python
    Mark Lawrence
    Oct 18, 2012
  5. Jean-Michel Pichavant

    Re: A desperate lunge for on-topic-ness

    Jean-Michel Pichavant, Oct 18, 2012, in forum: Python
    Demian Brecht
    Oct 19, 2012

Share This Page