style question

[Hari Sekhon]

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.

 

[MTD]

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"

 

[Frank Millman]

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]

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

 

[Laurent Rahuel]

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.

 

[Fredrik Lundh]

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>

 

[Frank Millman]

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

 

[Duncan Booth]

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:
This is line1.
This is line2
This is line3
""")'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
"""

 

[Claudio Grondi]

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

 

[Scott David Daniels]

Claudio Grondi wrote:

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
(e-mail address removed)

 

[Claudio Grondi]

Claudio Grondi wrote:

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

 

[Hari Sekhon]

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
(e-mail address removed) <mailto:[email protected]>

--
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

 

[Jorgen Grahn]

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.

 

[Fredrik Lundh]

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>

 

[Scott David Daniels]

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
(e-mail address removed)

 

[Jorgen Grahn]

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]

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]

Jorgen Grahn wrote: ....

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

 

[Nick Maclaren]

|>
|> 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.

 

[Scott David Daniels]

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
(e-mail address removed)