By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,906 Members | 1,767 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,906 IT Pros & Developers. It's quick & easy.

style question

P: n/a
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.

Jun 26 '06 #1
Share this Question
Share on Google+
21 Replies


P: n/a
MTD

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"

Jun 26 '06 #2

P: n/a

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

Jun 26 '06 #3

P: n/a

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

Jun 26 '06 #4

P: n/a
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.
Jun 26 '06 #5

P: n/a
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>

Jun 26 '06 #6

P: n/a

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

Jun 26 '06 #7

P: n/a
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
"""
Jun 26 '06 #8

P: n/a
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
Jun 26 '06 #9

P: n/a
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
sc***********@acm.org
Jun 26 '06 #10

P: n/a
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
sc***********@acm.org

Jun 26 '06 #11

P: n/a
Claudio Grondi wrote:
Hari Sekhon wrote:
On 26/06/06, *Claudio Grondi* <cl************@freenet.de
<mailto:cl************@freenet.de>> 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
> sc***********@acm.org <mailto:sc***********@acm.org>

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

Jun 27 '06 #12

P: n/a
On Mon, 26 Jun 2006 11:47:21 +0200, Fredrik Lundh <fr*****@pythonware.com> 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!
Jun 29 '06 #13

P: n/a
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>

Jun 29 '06 #14

P: n/a
Jorgen Grahn wrote:
On Mon, 26 Jun 2006 11:47:21 +0200, Fredrik Lundh <fr*****@pythonware.com> 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
sc***********@acm.org
Jun 29 '06 #15

P: n/a
On Thu, 29 Jun 2006 15:31:53 -0700, Scott David Daniels <sc***********@acm.org> 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!
Jul 1 '06 #16

P: n/a
On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh <fr*****@pythonware.com> 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!
Jul 1 '06 #17

P: n/a
On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh <fr*****@pythonware.com> 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!
Jul 1 '06 #18

P: n/a

In article <sl***********************@frailea.sa.invalid>,
Jorgen Grahn <gr********@snipabacken.dyndns.org> 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.
Jul 1 '06 #19

P: n/a
Jorgen Grahn wrote:
On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh <fr*****@pythonware.com> 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
sc***********@acm.org
Jul 1 '06 #20

P: n/a
Scott David Daniels <sc***********@acm.orgwrote:
>
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).
"Ransom note syndrome." Virtually everyone falls prey to this the first
few times they discover desktop publishing.
>All of this was in the mid seventies or earlier.
Right. It surprises many people to learn that virtually everything we
think of as modern and interesting in computer science was first explored
in the 1960s and early 1970s. GUIs, color, 3D, structured progamming,
networking, interpreters, Unix; the list goes on and on. It was probably
the most exciting time in the history of computers.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Jul 2 '06 #21

P: n/a
Tim Roberts wrote:
It surprises many people to learn that virtually everything we
think of as modern and interesting in computer science was first explored
in the 1960s and early 1970s. GUIs, color, 3D, structured progamming,
networking, interpreters, Unix; the list goes on and on. It was probably
the most exciting time in the history of computers.
Here I think you're wrong, my vote is the 1940s:
First time for tons of stuff, fate of the world hangs in the
balance, no idea if some of this is going to work, ....
Essentially all the crypto push with top secret machines decoding
German traffic, and the desperate attempt to crack the Japanese
Purple system. I expect the efforts at Bletchley Park, Princeton,
numerous unnamed locations, and even Germany and Japan were pulse-
pounding. In the sixties and seventies we were just having immense
fun making things go, at least by comparison.

--Scott David Daniels
sc***********@acm.org
Jul 2 '06 #22

This discussion thread is closed

Replies have been disabled for this discussion.