style question

Discussion in 'Python' started by Hari Sekhon, Jun 26, 2006.

  1. Hari Sekhon

    Hari Sekhon Guest

    Is it better to do:

    message = """This is line1.
    This is line2
    This is line3\n"""

    or

    message = "This is line1.\n
    message = message + "This is line2\n"
    message = message + "This is line3\n"


    Since the first method does not follow python's clean and easy looking
    indentation structure but the second just looks crude and ugly anyway.

    If I indent the first version so the text is lined up to match code
    indentation then this comes out in the input and isn't aligned there.
    Hari Sekhon, Jun 26, 2006
    #1
    1. Advertising

  2. Hari Sekhon

    MTD Guest

    Hari Sekhon wrote:
    > Is it better to do:
    >
    > message = """This is line1.
    > This is line2
    > This is line3\n"""
    >
    > or
    >
    > message = "This is line1.\n
    > message = message + "This is line2\n"
    > message = message + "This is line3\n"


    Is there any reason you can't do it in one line?

    message = "This is line1.\nThis is line2.\nThis is line3.\n"
    MTD, Jun 26, 2006
    #2
    1. Advertising

  3. Hari Sekhon wrote:
    > Is it better to do:
    >
    > message = """This is line1.
    > This is line2
    > This is line3\n"""
    >
    > or
    >
    > message = "This is line1.\n
    > message = message + "This is line2\n"
    > message = message + "This is line3\n"
    >
    >
    > Since the first method does not follow python's clean and easy looking
    > indentation structure but the second just looks crude and ugly anyway.
    >
    > If I indent the first version so the text is lined up to match code
    > indentation then this comes out in the input and isn't aligned there.


    How about

    message = ("This is line1. "
    "This is line2 "
    "This is line3\n")

    The brackets mean that the lines are automatically treated as
    continuous, without the need for the ugly '\' continuation character.

    The opening/closing quotes on each line mean that the strings are
    contatenated into one long string.

    Frank Millman
    Frank Millman, Jun 26, 2006
    #3
  4. Frank Millman wrote:
    >
    > How about
    >
    > message = ("This is line1. "
    > "This is line2 "
    > "This is line3\n")
    >
    > The brackets mean that the lines are automatically treated as
    > continuous, without the need for the ugly '\' continuation character.
    >
    > The opening/closing quotes on each line mean that the strings are
    > contatenated into one long string.
    >
    > Frank Millman


    Don't know what happened there - Google seems to have messed up my
    indentation.

    My intention was that each of the three leading quote marks line up
    vertically, but when I read it back via Google Groups, the second two
    lines were pushed over to the right.

    Frank
    Frank Millman, Jun 26, 2006
    #4
  5. Hari Sekhon wrote:

    > Is it better to do:
    >
    > message = """This is line1.
    > This is line2
    > This is line3\n"""
    >
    > or
    >
    > message = "This is line1.\n
    > message = message + "This is line2\n"
    > message = message + "This is line3\n"
    >
    >
    > Since the first method does not follow python's clean and easy looking
    > indentation structure but the second just looks crude and ugly anyway.
    >
    > If I indent the first version so the text is lined up to match code
    > indentation then this comes out in the input and isn't aligned there.


    Hi,

    msgs = ['This is line1.','This is line2.','This is line3.']
    message = '\n'.join(msgs)

    Regards,

    Laurent.
    Laurent Rahuel, Jun 26, 2006
    #5
  6. Frank Millman wrote:

    >> How about
    >>
    >> message = ("This is line1. "
    >> "This is line2 "
    >> "This is line3\n")
    >>
    >> The brackets mean that the lines are automatically treated as
    >> continuous, without the need for the ugly '\' continuation character.
    >>
    >> The opening/closing quotes on each line mean that the strings are
    >> contatenated into one long string.

    >
    > Don't know what happened there - Google seems to have messed up my
    > indentation.
    >
    > My intention was that each of the three leading quote marks line up
    > vertically, but when I read it back via Google Groups, the second two
    > lines were pushed over to the right.


    assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable indentation
    no matter what font you're using, you can write:

    message = (
    "This is line1. "
    "This is line2 "
    "This is line3\n")

    whether this is better than """ depends on the situation.

    </F>
    Fredrik Lundh, Jun 26, 2006
    #6
  7. Fredrik Lundh wrote:
    > Frank Millman wrote:
    >
    > >> How about
    > >>
    > >> message = ("This is line1. "
    > >> "This is line2 "
    > >> "This is line3\n")
    > >>
    > >> The brackets mean that the lines are automatically treated as
    > >> continuous, without the need for the ugly '\' continuation character.
    > >>
    > >> The opening/closing quotes on each line mean that the strings are
    > >> contatenated into one long string.

    > >
    > > Don't know what happened there - Google seems to have messed up my
    > > indentation.
    > >
    > > My intention was that each of the three leading quote marks line up
    > > vertically, but when I read it back via Google Groups, the second two
    > > lines were pushed over to the right.

    >
    > assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable indentation
    > no matter what font you're using, you can write:
    >
    > message = (
    > "This is line1. "
    > "This is line2 "
    > "This is line3\n")
    >
    > whether this is better than """ depends on the situation.
    >
    > </F>


    Obvious, now that you mention it.

    Thank you.

    Frank
    Frank Millman, Jun 26, 2006
    #7
  8. Hari Sekhon

    Duncan Booth Guest

    Hari Sekhon wrote:

    > Since the first method does not follow python's clean and easy looking
    > indentation structure but the second just looks crude and ugly anyway.


    If you want indented and pretty is important to you:

    >>> from textwrap import dedent as D
    >>> message = D("""\

    This is line1.
    This is line2
    This is line3
    """)
    >>> message

    'This is line1.\nThis is line2\nThis is line3\n'

    Usually though I would just make sure that long strings are declared at
    module level and not indent them. The backslash after the opening quotes
    stops the first line being indented differently:

    message = """\
    This is line1.
    This is line2
    This is line3
    """
    Duncan Booth, Jun 26, 2006
    #8
  9. Hari Sekhon wrote:
    > Is it better to do:
    >
    > message = """This is line1.
    > This is line2
    > This is line3\n"""
    >
    > or
    >
    > message = "This is line1.\n
    > message = message + "This is line2\n"
    > message = message + "This is line3\n"
    >
    >
    > Since the first method does not follow python's clean and easy looking
    > indentation structure but the second just looks crude and ugly anyway.
    >
    > If I indent the first version so the text is lined up to match code
    > indentation then this comes out in the input and isn't aligned there.
    >

    What about

    message = """
    This is line 1
    This is line 2
    This is line 3
    """

    When it is necessary to skip first empty line):
    message = """
    This is line 1
    This is line 2
    This is line 3
    """[1:]


    When necessary to skip first line _and_ indentation:
    message = """
    This is line 1
    This is line 2
    This is line 3
    """.replace('\n ', '\n')[1:] # adjust here '\n ' to indentation
    # ^-- gives 'This is line 1\nThis is line 2\nThis is line 3\n'

    ?

    Claudio
    Claudio Grondi, Jun 26, 2006
    #9
  10. Claudio Grondi wrote:
    <<<clever stuff to di indentation>>>
    > When necessary to skip first line _and_ indentation:
    > message = """
    > This is line 1
    > This is line 2
    > This is line 3
    > """.replace('\n ', '\n')[1:] # adjust here '\n ' to indentation


    Riffing on this idea:
    message = """
    This is line 1
    This is line 2
    This is line 3
    """.replace("""
    """, '\n')[1:]

    --Scott David Daniels
    Scott David Daniels, Jun 26, 2006
    #10
  11. Scott David Daniels wrote:
    > Claudio Grondi wrote:
    > <<<clever stuff to di indentation>>>
    >
    >> When necessary to skip first line _and_ indentation:
    >> message = """
    >> This is line 1
    >> This is line 2
    >> This is line 3
    >> """.replace('\n ', '\n')[1:] # adjust here '\n ' to indentation

    >
    >
    > Riffing on this idea:
    > message = """
    > This is line 1
    > This is line 2
    > This is line 3
    > """.replace("""
    > """, '\n')[1:]


    This was intended as an excercise for the OP in case he likes that kind
    of solution ...

    Claudio

    >
    > --Scott David Daniels
    >
    Claudio Grondi, Jun 26, 2006
    #11
  12. Hari Sekhon

    Hari Sekhon Guest

    Claudio Grondi wrote:
    > Hari Sekhon wrote:
    >> On 26/06/06, *Claudio Grondi* <
    >> <mailto:>> wrote:
    >>
    >> Scott David Daniels wrote:
    >> > Claudio Grondi wrote:
    >> > <<<clever stuff to di indentation>>>
    >> >
    >> >> When necessary to skip first line _and_ indentation:
    >> >> message = """
    >> >> This is line 1
    >> >> This is line 2
    >> >> This is line 3
    >> >> """.replace('\n ', '\n')[1:] # adjust here '\n ' to

    >> indentation
    >> >
    >> >
    >> > Riffing on this idea:
    >> > message = """
    >> > This is line 1
    >> > This is line 2
    >> > This is line 3
    >> > """.replace("""
    >> > """, '\n')[1:]

    >>
    >> This was intended as an excercise for the OP in case he likes
    >> that kind
    >> of solution ...
    >>
    >> Claudio
    >>
    >> >
    >> > --Scott David Daniels
    >> > <mailto:>

    >> --
    >> http://mail.python.org/mailman/listinfo/python-list
    >>
    >>
    >> I've decided to go with
    >>
    >> message = (
    >> "This is line1. "
    >> "This is line2 "
    >> "This is line3\n")
    >>
    >> since I'm declaring many different messages inside various functions
    >> I feel it is important to keep the indentaion and code both aligned
    >> properly so the code looks nice and the output looks nice.
    >>
    >> It is easier than doing replace and splicing since I want to keep it
    >> as simple and clean as possible, in true pythonic tradition...
    >>
    >> Thanks for the input!
    >>
    >> -h
    >>

    > Thanks for the reply and the explanation what you finally decided to
    > go with.
    > I am so happy to have the triple quotes in Python, that I use them
    > whenever possible - this has probably something to do with my bias
    > towards plain text files with human readable content, so as
    > readability is very important to me (and probably to many other
    > Pythonistas) I like most the proposed by me triple quote style as the
    > quotation marks in the style you prefer make the text of the 'message'
    > less easy to read.
    >
    > Now we can start a flame war about which style is more 'pythonic' ;-)
    >
    > Claudio
    >

    I already explained that the triple quotes don't work tidily with
    indentation, either the code is out of alignment or the printout is.
    Either way isn't good.
    Triple quotes are best at top level, but since I had to use many
    messages inside functions etc, they broke the layout of the code.

    I think they're both best depending on where you are putting them. I'm
    doing very custom messages for each different result, so it would be
    messy to do this at the top level.

    -h
    Hari Sekhon, Jun 27, 2006
    #12
  13. Hari Sekhon

    Jorgen Grahn Guest

    On Mon, 26 Jun 2006 11:47:21 +0200, Fredrik Lundh <> wrote:
    ....
    > assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable indentation
    > no matter what font you're using, you can write [...]


    Since when? I've always coded, in all languages I've ever used[1], under the
    assumption that the reader will view it with a fixed-pitch (or whatever the
    proper term is) font. I assumed everyone else did, too. I still assume that,
    in fact -- noone has ever come up to me and said "hey, that code you wrote
    looks ugly in Comic Sans MS".

    (I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
    system for C++ code, where identifiers and strings are in Times italic,
    operators in Courier, and so on.)

    /Jorgen

    [1] Too young for punch cards.

    --
    // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
    Jorgen Grahn, Jun 29, 2006
    #13
  14. Jorgen Grahn wrote:

    >> assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable indentation
    >> no matter what font you're using, you can write [...]

    >
    > Since when? I've always coded, in all languages I've ever used[1], under the
    > assumption that the reader will view it with a fixed-pitch (or whatever the
    > proper term is) font. I assumed everyone else did, too.


    that's a popular myth.

    > (I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
    > system for C++ code, where identifiers and strings are in Times italic,
    > operators in Courier, and so on.)


    the idea of printing everything in courier (or some other monospace
    font) is a rather new idea; if you read seventies stuff, the program
    code is often as carefully designed as the rest of the document.

    (for an indication that we might be moving back to nicely rendered code,
    see Sun's new Fortress language, which provides extraordinarily detailed
    control over how identifiers are rendered, including extensive support
    for Unicode and math notation. it also mandates the use of proportional
    fonts for things like identifiers and comments...)

    </F>
    Fredrik Lundh, Jun 29, 2006
    #14
  15. Jorgen Grahn wrote:
    > On Mon, 26 Jun 2006 11:47:21 +0200, Fredrik Lundh <> wrote:
    > ...
    >> assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable indentation
    >> no matter what font you're using, you can write [...]

    >
    > Since when? I've always coded, in all languages I've ever used[1], under the
    > assumption that the reader will view it with a fixed-pitch ... font. I assumed
    > everyone else did, too....
    > I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
    > system for C++ code, ....

    See Knuth on Literate Programming and the "Web" systems (e.g. CWeb).
    His goal is to look good typeset with explanation, and extract-to-compile.

    --Scott David Daniels
    Scott David Daniels, Jun 29, 2006
    #15
  16. Hari Sekhon

    Jorgen Grahn Guest

    On Thu, 29 Jun 2006 15:31:53 -0700, Scott David Daniels <> wrote:
    ....
    >> I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
    >> system for C++ code, ....


    > See Knuth on Literate Programming and the "Web" systems (e.g. CWeb).
    > His goal is to look good typeset with explanation, and extract-to-compile.


    Yes, I'm aware of Knuth's work, and didn't mean to imply that Stroustrup did
    something revolutionary -- although his book and Bertrand Meyer's Eiffel
    book are the only ones I've read which try do something elegant with the
    code typesetting.

    I haven't read Knuth until now, so I assumed he typeset the actual code
    parts fixed-width. I see in the CWeb manual that that's not the case.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
    Jorgen Grahn, Jul 1, 2006
    #16
  17. Hari Sekhon

    Jorgen Grahn Guest

    On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh <> wrote:
    > Jorgen Grahn wrote:
    >
    >>> assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable indentation
    >>> no matter what font you're using, you can write [...]

    >>
    >> Since when? I've always coded, in all languages I've ever used[1], under the
    >> assumption that the reader will view it with a fixed-pitch (or whatever the
    >> proper term is) font. I assumed everyone else did, too.

    >
    > that's a popular myth.


    I'm sorry, you will have to come up with some real references to convince me
    (a PEP or preferrably something not Python-specific). Or not, because I will
    keep assuming a fixed-width font in my programming anyway. Living the myth!

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
    Jorgen Grahn, Jul 1, 2006
    #17
  18. Hari Sekhon

    Jorgen Grahn Guest

    Non-ASCII languages (was: Re: style question)

    On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh <> wrote:
    > Jorgen Grahn wrote:

    ....
    >> (I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
    >> system for C++ code, where identifiers and strings are in Times italic,
    >> operators in Courier, and so on.)

    >
    > the idea of printing everything in courier (or some other monospace
    > font) is a rather new idea; if you read seventies stuff, the program
    > code is often as carefully designed as the rest of the document.


    Possibly true, and definitely for Knuth. But WYSIWYG was unknown at the
    time; these people all programmed using fixed-width fonts, on teletypes or
    character-mapped terminals. Hell, even full-screen editors were new and
    controversial until the late 1970s!

    Program editing and displaying/typesetting can be treated as separate from
    each other. Personally, I think they /should/ be -- I prefer troff or LaTeX
    to MS Word, after all.

    > (for an indication that we might be moving back to nicely rendered code,
    > see Sun's new Fortress language, which provides extraordinarily detailed
    > control over how identifiers are rendered, including extensive support
    > for Unicode and math notation. it also mandates the use of proportional
    > fonts for things like identifiers and comments...)


    And Sun apparently think they should not be separate.
    To me, it looks like they are planning for this language to fail.

    If I wanted to try out this language, I would have to give up most of my
    existing toolbox -- which works flawlessly with everything from TI assembly
    to Python. And what would people discuss on comp.lang.fortress? Google
    destroys Python code well enough ...

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
    Jorgen Grahn, Jul 1, 2006
    #18
  19. Re: Non-ASCII languages (was: Re: style question)

    In article <>,
    Jorgen Grahn <> writes:
    |>
    |> Possibly true, and definitely for Knuth. But WYSIWYG was unknown at the
    |> time; these people all programmed using fixed-width fonts, on teletypes or
    |> character-mapped terminals. Hell, even full-screen editors were new and
    |> controversial until the late 1970s!

    A slight niggle - WYSIWYG wasn't unknown, just both rare and not yet
    called that! I have programmed using devices with half-line shifts,
    real backspacing and so on - and some languages did mandate that a
    character created by overprinting was to be treated as a composite
    character.

    Also, there were full-screen editors for things like IBM 3270s, though
    they were absolutely ghastly for editing text (being designed for form
    filling).

    I agree with you that neither those days nor gimmicky approaches like
    that of Fortress are worth pursuing. One of the main reasons that
    'program proving' has never taken off outside its cabal is that it
    uses bizarre notations unlike anything else on earth that can't be
    edited in a normal fashion.


    Regards,
    Nick Maclaren.
    Nick Maclaren, Jul 1, 2006
    #19
  20. Re: Non-ASCII languages

    Jorgen Grahn wrote:
    > On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh <> wrote:
    >> Jorgen Grahn wrote:

    > ...
    >>> (I like well-typeset code in print though....

    > Possibly true, and definitely for Knuth. But WYSIWYG was unknown at the
    > time; these people all programmed using fixed-width fonts, on teletypes or
    > character-mapped terminals. Hell, even full-screen editors were new and
    > controversial until the late 1970s!

    Sorry, I'm old enough to have a few problems with this. WYSIWIG was
    indeed well known at the time, and disparaged as WYSIAYG around where I
    worked (What You See Is All You Get). We had full screen editors, with
    proportional fonts; SAIL (Stanford AI Lab) had the first laser printer
    to play with (people wrote incredibly ugly documents with tons of fonts
    in them because it was the first they could spec it). All of this was
    in the mid seventies or earlier.

    --Scott David Daniels
    Scott David Daniels, Jul 1, 2006
    #20
    1. Advertising

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. Rob Nicholson
    Replies:
    3
    Views:
    656
    Rob Nicholson
    May 28, 2005
  2. Replies:
    0
    Views:
    2,438
  3. Replies:
    1
    Views:
    779
    Bertilo Wennergren
    Nov 24, 2003
  4. Hardeep Rakhra
    Replies:
    8
    Views:
    628
    Hardeep Rakhra
    Jan 15, 2004
  5. Ken Varn
    Replies:
    0
    Views:
    423
    Ken Varn
    Apr 26, 2004
Loading...

Share This Page