Hot to split string literals that will across two or more lines ?

[Xiao Jianfeng]

Hi,

I need to print a long sting, which is two long so it must expand two
lines.
I know that we can use backslash(\) to explicitly join two lines into a
logical line,
but this doesn't work for string literals :(

my code:
-----------------------------------------------------------------------------
if sth.:
print "a string whcih is very very looooooooooooooooooooooooooooooooooo\
oooooooooooooooooooong."
-----------------------------------------------------------------------------

If I don't break the line, it will be very ugly, if I break the
line,....but how ?

Thanks in advance!

xiaojf

[jmdeschamps]

Xiao Jianfeng wrote:

Hi,

I need to print a long sting, which is two long so it must expand two
lines.
I know that we can use backslash(\) to explicitly join two lines into a
logical line,
but this doesn't work for string literals :(

my code:
-----------------------------------------------------------------------------
if sth.:
print "a string whcih is very very looooooooooooooooooooooooooooooooooo\
oooooooooooooooooooong."
-----------------------------------------------------------------------------

If I don't break the line, it will be very ugly, if I break the
line,....but how ?

Thanks in advance! in python there are triple quoted strings:
strVar = """this the beginning
and this is the end """
xiaojf

[jmdeschamps]

Xiao Jianfeng wrote:

Hi,

I need to print a long sting, which is two long so it must expand two
lines.
I know that we can use backslash(\) to explicitly join two lines into a
logical line,
but this doesn't work for string literals :(

my code:
-----------------------------------------------------------------------------
if sth.:
print "a string whcih is very very looooooooooooooooooooooooooooooooooo\
oooooooooooooooooooong."
-----------------------------------------------------------------------------

If I don't break the line, it will be very ugly, if I break the
line,....but how ?

Thanks in advance! in python there are triple quoted strings:
strVar = """this the beginning
and this is the end """
xiaojf

[Lars Kellogg-Stedman]

> print "a string whcih is very very looooooooooooooooooooooooooooooooooo\

oooooooooooooooooooong."

print "a string which is very loooooo" \
+ "ooooong."

-- Lars

--
Lars Kellogg-Stedman <82*************@jetable.net>
This email address will expire on 2005-11-23.

[Lars Kellogg-Stedman]

> print "a string whcih is very very looooooooooooooooooooooooooooooooooo\

oooooooooooooooooooong."

print "a string which is very loooooo" \
+ "ooooong."

-- Lars

--
Lars Kellogg-Stedman <82*************@jetable.net>
This email address will expire on 2005-11-23.

[Sam Pointon]

> print "a string which is very loooooo" \

+ "ooooong."

Minor pedantry, but the plus sign is redundant. Python automatically
concatenates string literals on the same logical line separated by only
whitespace.

[Sam Pointon]

> print "a string which is very loooooo" \

+ "ooooong."

Minor pedantry, but the plus sign is redundant. Python automatically
concatenates string literals on the same logical line separated by only
whitespace.

[Xiao Jianfeng]

jm*********@gmail.com wrote:

Xiao Jianfeng wrote:

Hi,

I need to print a long sting, which is two long so it must expand two
lines.
I know that we can use backslash(\) to explicitly join two lines into a
logical line,
but this doesn't work for string literals :(

my code:
-----------------------------------------------------------------------------
if sth.:
print "a string whcih is very very looooooooooooooooooooooooooooooooooo\
oooooooooooooooooooong."
-----------------------------------------------------------------------------

If I don't break the line, it will be very ugly, if I break the
line,....but how ?

Thanks in advance!

in python there are triple quoted strings:
strVar = """this the beginning
and this is the end """

Thanks.
But even I use triple quoted strings instead , there is still extra
space before "and this...".
The string I want to print is in a "if" statement, so it is not at the
beginning of the line.

xiaojf

[Xiao Jianfeng]

jm*********@gmail.com wrote:

Xiao Jianfeng wrote:

Hi,

I need to print a long sting, which is two long so it must expand two
lines.
I know that we can use backslash(\) to explicitly join two lines into a
logical line,
but this doesn't work for string literals :(

my code:
-----------------------------------------------------------------------------
if sth.:
print "a string whcih is very very looooooooooooooooooooooooooooooooooo\
oooooooooooooooooooong."
-----------------------------------------------------------------------------

If I don't break the line, it will be very ugly, if I break the
line,....but how ?

Thanks in advance!

in python there are triple quoted strings:
strVar = """this the beginning
and this is the end """

Thanks.
But even I use triple quoted strings instead , there is still extra
space before "and this...".
The string I want to print is in a "if" statement, so it is not at the
beginning of the line.

xiaojf

[rurpy]

You can leave out the "+" if you want, adjacent strings are
automatically
concatenated.

print "a string which is very loooooo" \
"ooooong."

Perhaps this is more efficient, since the string concatenation can be
done by Python's parser rather than at runtime?

Lars Kellogg-Stedman <[e-mail]> wrote:

print "a string whcih is very very looooooooooooooooooooooooooooooooooo\
oooooooooooooooooooong."

print "a string which is very loooooo" \
+ "ooooong."

-- Lars

--
Lars Kellogg-Stedman <[e-mail]>
This email address will expire on 2005-11-23.

[Lars Kellogg-Stedman]

> Minor pedantry, but the plus sign is redundant.

Thanks for catching that...I haven't been working with Python as much as
I was a year or so ago and I'm forgetting some of the details.

-- Lars

--
Lars Kellogg-Stedman <82*************@jetable.net>
This email address will expire on 2005-11-23.

[rurpy]

You can leave out the "+" if you want, adjacent strings are
automatically
concatenated.

print "a string which is very loooooo" \
"ooooong."

Perhaps this is more efficient, since the string concatenation can be
done by Python's parser rather than at runtime?

Lars Kellogg-Stedman <[e-mail]> wrote:

print "a string whcih is very very looooooooooooooooooooooooooooooooooo\
oooooooooooooooooooong."

print "a string which is very loooooo" \
+ "ooooong."

-- Lars

--
Lars Kellogg-Stedman <[e-mail]>
This email address will expire on 2005-11-23.

[Lars Kellogg-Stedman]

> Minor pedantry, but the plus sign is redundant.

Thanks for catching that...I haven't been working with Python as much as
I was a year or so ago and I'm forgetting some of the details.

-- Lars

--
Lars Kellogg-Stedman <82*************@jetable.net>
This email address will expire on 2005-11-23.

[Xiao Jianfeng]

Lars Kellogg-Stedman wrote:

print "a string whcih is very very looooooooooooooooooooooooooooooooooo\
oooooooooooooooooooong."

print "a string which is very loooooo" \
+ "ooooong."

-- Lars

Oh, Thank you!

[Xiao Jianfeng]

Lars Kellogg-Stedman wrote:

print "a string whcih is very very looooooooooooooooooooooooooooooooooo\
oooooooooooooooooooong."

print "a string which is very loooooo" \
+ "ooooong."

-- Lars

Oh, Thank you!

[Ben Finney]

Xiao Jianfeng <fd********@gmail.com> wrote:

I need to print a long sting, which is two long so it must expand
two lines.

How is this string being constructed in the source? If it exists as a
single long string, why must it be so long?

Some techniques you may not be aware of:

chunks = ["abc", "def", "ghi"]
s = ''.join(chunks)
print s abcdefghi
s = "#" * 10
print s

##########

You can, of course, modify the above so that they join or multiply to
create much longer strings.

--
\ "Everything is futile." -- Marvin of Borg |
`\ |
_o__) |
Ben Finney

[Ben Finney]

Xiao Jianfeng <fd********@gmail.com> wrote:

I need to print a long sting, which is two long so it must expand
two lines.

How is this string being constructed in the source? If it exists as a
single long string, why must it be so long?

Some techniques you may not be aware of:

chunks = ["abc", "def", "ghi"]
s = ''.join(chunks)
print s abcdefghi
s = "#" * 10
print s

##########

You can, of course, modify the above so that they join or multiply to
create much longer strings.

--
\ "Everything is futile." -- Marvin of Borg |
`\ |
_o__) |
Ben Finney

[Tony Nelson]

In article <11**********************@g49g2000cwa.googlegroups .com>,
"Sam Pointon" <fr*************@gmail.com> wrote:

print "a string which is very loooooo" \
+ "ooooong."

Minor pedantry, but the plus sign is redundant. Python automatically
concatenates string literals on the same logical line separated by only
whitespace.

While we're at it, I use bracketing instead of line continuation:

print ( "a long string, longer than this "
"and some more of the string" )
__________________________________________________ ______________________
TonyN.:' *firstname*nlsnews@georgea*lastname*.com
' <http://www.georgeanelson.com/>

[Tony Nelson]

In article <11**********************@g49g2000cwa.googlegroups .com>,
"Sam Pointon" <fr*************@gmail.com> wrote:

print "a string which is very loooooo" \
+ "ooooong."

Minor pedantry, but the plus sign is redundant. Python automatically
concatenates string literals on the same logical line separated by only
whitespace.

While we're at it, I use bracketing instead of line continuation:

print ( "a long string, longer than this "
"and some more of the string" )
__________________________________________________ ______________________
TonyN.:' *firstname*nlsnews@georgea*lastname*.com
' <http://www.georgeanelson.com/>

[Ben Finney]

Tony Nelson <*firstname*nlsnews@georgea*lastname*.com> wrote:

While we're at it, I use bracketing instead of line continuation:

print ( "a long string, longer than this "
"and some more of the string" )

To continue the pedantry: Those are parentheses, not brackets.

Slightly more on-topic, the parentheses make it look like a sequence
to this reader (though, without a comma, not to the Python parser, of
course).

--
\ Q: "I've heard that Linux causes cancer..." Torvalds: "That's |
`\ a filthy lie. Besides, it was only in rats and has not been |
_o__) reproduced in humans." -- Linus Torvalds |
Ben Finney

[Ben Finney]

Tony Nelson <*firstname*nlsnews@georgea*lastname*.com> wrote:

While we're at it, I use bracketing instead of line continuation:

print ( "a long string, longer than this "
"and some more of the string" )

To continue the pedantry: Those are parentheses, not brackets.

Slightly more on-topic, the parentheses make it look like a sequence
to this reader (though, without a comma, not to the Python parser, of
course).

--
\ Q: "I've heard that Linux causes cancer..." Torvalds: "That's |
`\ a filthy lie. Besides, it was only in rats and has not been |
_o__) reproduced in humans." -- Linus Torvalds |
Ben Finney

[Bengt Richter]

On Fri, 18 Nov 2005 11:33:57 +0800, Xiao Jianfeng <fd********@gmail.com> wrote:

Lars Kellogg-Stedman wrote:

print "a string whcih is very very looooooooooooooooooooooooooooooooooo\
oooooooooooooooooooong."

print "a string which is very loooooo" \
+ "ooooong."

Personally, I prefer to use a parenthesized expression format instead of "\" and
(as has been mentioned) to remove the '+' between adjacent string literals,
since the tokenizer will join adjacent string literals into one to generate
a single constant. This is more efficient at run time also, since there are no
byte codes generated for the adding. E.g., the above becomes

print ("a string which is very loooooo"
"ooooong.")

or formatted however you please. Sometimes if the substring source code is machine generated,
it is handy to bracket the substrings between a header line and a trailer line, e.g.,

print (
"a string which is very loooooo"
"ooooong."
)

Regards,
Bengt Richter

[Bengt Richter]

On Fri, 18 Nov 2005 11:33:57 +0800, Xiao Jianfeng <fd********@gmail.com> wrote:

Lars Kellogg-Stedman wrote:

print "a string whcih is very very looooooooooooooooooooooooooooooooooo\
oooooooooooooooooooong."

print "a string which is very loooooo" \
+ "ooooong."

Personally, I prefer to use a parenthesized expression format instead of "\" and
(as has been mentioned) to remove the '+' between adjacent string literals,
since the tokenizer will join adjacent string literals into one to generate
a single constant. This is more efficient at run time also, since there are no
byte codes generated for the adding. E.g., the above becomes

print ("a string which is very loooooo"
"ooooong.")

or formatted however you please. Sometimes if the substring source code is machine generated,
it is handy to bracket the substrings between a header line and a trailer line, e.g.,

print (
"a string which is very loooooo"
"ooooong."
)

Regards,
Bengt Richter

[Alex Martelli]

Ben Finney <bi****************@benfinney.id.au> wrote:

Tony Nelson <*firstname*nlsnews@georgea*lastname*.com> wrote:

While we're at it, I use bracketing instead of line continuation:

print ( "a long string, longer than this "
"and some more of the string" )

To continue the pedantry: Those are parentheses, not brackets.

Slightly more on-topic, the parentheses make it look like a sequence
to this reader (though, without a comma, not to the Python parser, of
course).

Nevertheless, my favorite style has also always been to use parentheses,
and I was glad to see, on joining Google and studying its in-house
Python style guide, that Google mandates that style, too. After all,
though they're overloaded, it's _commas_ that make a tuple, not
parentheses, which essentially just *group* things (in cases where the
language's syntax would otherwise not suit you). So, you always do have
to watch out for commas, ayway, since, e.g.,

x = "Sempre caro", "mi fu"

and

x = "Sempre caro mi fu"

are so different -- it makes no difference whether either or both of
these assigments use parentheses (after the = and at line end), it's the
comma that does make all the difference. So, you can see it as a very
good side effect of the "long string use parentheses, not backslashes"
style rule, that the reader is soon weaned of the mistake of believing
that parentheses signify tuples.
Alex

[Alex Martelli]

Ben Finney <bi****************@benfinney.id.au> wrote:

Tony Nelson <*firstname*nlsnews@georgea*lastname*.com> wrote:

While we're at it, I use bracketing instead of line continuation:

print ( "a long string, longer than this "
"and some more of the string" )

To continue the pedantry: Those are parentheses, not brackets.

Slightly more on-topic, the parentheses make it look like a sequence
to this reader (though, without a comma, not to the Python parser, of
course).

Nevertheless, my favorite style has also always been to use parentheses,
and I was glad to see, on joining Google and studying its in-house
Python style guide, that Google mandates that style, too. After all,
though they're overloaded, it's _commas_ that make a tuple, not
parentheses, which essentially just *group* things (in cases where the
language's syntax would otherwise not suit you). So, you always do have
to watch out for commas, ayway, since, e.g.,

x = "Sempre caro", "mi fu"

and

x = "Sempre caro mi fu"

are so different -- it makes no difference whether either or both of
these assigments use parentheses (after the = and at line end), it's the
comma that does make all the difference. So, you can see it as a very
good side effect of the "long string use parentheses, not backslashes"
style rule, that the reader is soon weaned of the mistake of believing
that parentheses signify tuples.
Alex

[Steven D'Aprano]

On Fri, 18 Nov 2005 15:59:30 +1100, Ben Finney wrote:

Tony Nelson <*firstname*nlsnews@georgea*lastname*.com> wrote:

While we're at it, I use bracketing instead of line continuation:

print ( "a long string, longer than this "
"and some more of the string" )

To continue the pedantry: Those are parentheses, not brackets.

To out-pedant your pedantry, "bracket" is a general term for any and all
of the various punctuation marks used to bracket a substring or phrase.
Brackets include:

parentheses or round brackets ( )
square brackets [ ]
braces or curly brackets { }
chevrons or angle brackets 〈 〉

The symbols for chevrons are not available on common keyboards, are not
available in ordinary ASCII, and may not show up correctly in many
typefaces, so a common alternative is to substitute less than and greater
than signs < > as brackets. HTML and XML use that convention.

Note that "square brackets" is the formal name for the specific
brackets which are square: the adjective is not redundant.

Double chevrons « » (and occasionally single) are used as quotation
marks in some European languages, for instance French and Italian, and
sometimes Dutch. When used as quote marks, the French term guillemet is
sometimes used as synonym for chevron.

--
Steven.

[Steven D'Aprano]

On Fri, 18 Nov 2005 15:59:30 +1100, Ben Finney wrote:

Tony Nelson <*firstname*nlsnews@georgea*lastname*.com> wrote:

While we're at it, I use bracketing instead of line continuation:

print ( "a long string, longer than this "
"and some more of the string" )

To continue the pedantry: Those are parentheses, not brackets.

To out-pedant your pedantry, "bracket" is a general term for any and all
of the various punctuation marks used to bracket a substring or phrase.
Brackets include:

parentheses or round brackets ( )
square brackets [ ]
braces or curly brackets { }
chevrons or angle brackets 〈 〉

The symbols for chevrons are not available on common keyboards, are not
available in ordinary ASCII, and may not show up correctly in many
typefaces, so a common alternative is to substitute less than and greater
than signs < > as brackets. HTML and XML use that convention.

Note that "square brackets" is the formal name for the specific
brackets which are square: the adjective is not redundant.

Double chevrons « » (and occasionally single) are used as quotation
marks in some European languages, for instance French and Italian, and
sometimes Dutch. When used as quote marks, the French term guillemet is
sometimes used as synonym for chevron.

--
Steven.

[Mike Meyer]

Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:

Brackets include:

parentheses or round brackets ( )
square brackets [ ]
braces or curly brackets { }
chevrons or angle brackets 〈 〉

The symbols for chevrons are not available on common keyboards, are not
available in ordinary ASCII, and may not show up correctly in many
typefaces, so a common alternative is to substitute less than and greater
than signs < > as brackets. HTML and XML use that convention.

Hmm. I'm used to seeing "angle brackets" - aka brokets - used to refer
to </>. That may be the convention you mention leaking across, though.

You imply that HTML/XML might use chevrons. I don't think that's the
case. They inherit their start/end tag characters from SGML's
default.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:

Brackets include:

parentheses or round brackets ( )
square brackets [ ]
braces or curly brackets { }
chevrons or angle brackets 〈 〉

The symbols for chevrons are not available on common keyboards, are not
available in ordinary ASCII, and may not show up correctly in many
typefaces, so a common alternative is to substitute less than and greater
than signs < > as brackets. HTML and XML use that convention.

Hmm. I'm used to seeing "angle brackets" - aka brokets - used to refer
to </>. That may be the convention you mention leaking across, though.

You imply that HTML/XML might use chevrons. I don't think that's the
case. They inherit their start/end tag characters from SGML's
default.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Steven D'Aprano]

On Sat, 19 Nov 2005 22:51:04 -0500, Mike Meyer wrote:

Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:

Brackets include:

parentheses or round brackets ( )
square brackets [ ]
braces or curly brackets { }
chevrons or angle brackets 〈 〉

The symbols for chevrons are not available on common keyboards, are not
available in ordinary ASCII, and may not show up correctly in many
typefaces, so a common alternative is to substitute less than and greater
than signs < > as brackets. HTML and XML use that convention.

Hmm. I'm used to seeing "angle brackets" - aka brokets - used to refer
to </>. That may be the convention you mention leaking across, though.

You imply that HTML/XML might use chevrons. I don't think that's the
case. They inherit their start/end tag characters from SGML's
default.

No! That's not what I said.

SGML-derived languages use greater-than and less-than symbols < > as if
they were brackets. That's practicality beats purity: true chevrons are
not available in ASCII or on common keyboards, making them difficult to
use. People commonly call < and > "angle brackets" in the context of HTML
etc. but they aren't really, they are mathematical comparison operator
signs.

Proper chevrons are narrower and taller. The difference between 〈 〉
and < > is *very* obvious in the font I'm using, although of course not
all fonts use the proper glyphs. If it helps, the angle on the inside of
the chevron is about 120 degrees, compared to maybe 60 degrees for the
comparison operators. Again, this depends on the precise glyph being used.

True angle brackets are available in Unicode at code points 9001 and 9002,
(0x2329 and 0x232A). The less-than and greater-than symbols can be found
in both Unicode and ASCII at code points 60 and 62 (0x003C and 0x003E).
I did warn in my earlier post that I was being pedantic. In common usage,
I'll describe <tag> as using angle brackets, just as I'll describe "quote"
as using quote marks. They're not actually: they are double-prime marks,
and ' is a prime mark not an apostrophe or quote mark. Prime and
double-prime marks are also known as foot and inch marks, although *real*
pedants would argue that there is a difference between them too. (I think
they get separate Unicode points.)
It is easy to get confused when it comes to characters, because there are
three separate but related things to keep in mind. Firstly, there is the
glyph or picture used, which differs according to the font and type-style.
Two different glyphs can represent the same symbol, and two identical
glyphs can represent different symbols.

Secondly, there is the semantic meaning of the character: a dash and a
hyphen are both horizontal lines, but they have very different meanings.
Dashes -- sometimes faked with two hyphens in a row like this -- are used
as separators, and hyphens are used to join compound words like
fire-fighting or anti-matter.

Thirdly, there is the specific implementation of the character. ASCII
defines only 127 characters, a good thirty-plus being invisible control
characters. Eight-bit extensions to ASCII unfortunately vary between each
other: the character 176 (0xB0) is the degree symbol in the Latin-1
encoding (ISO 8859-1) but the infinity symbol in the MacRoman encoding.

--
Steven.

[Steven D'Aprano]

On Sat, 19 Nov 2005 22:51:04 -0500, Mike Meyer wrote:

Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:

Brackets include:

parentheses or round brackets ( )
square brackets [ ]
braces or curly brackets { }
chevrons or angle brackets 〈 〉

The symbols for chevrons are not available on common keyboards, are not
available in ordinary ASCII, and may not show up correctly in many
typefaces, so a common alternative is to substitute less than and greater
than signs < > as brackets. HTML and XML use that convention.

Hmm. I'm used to seeing "angle brackets" - aka brokets - used to refer
to </>. That may be the convention you mention leaking across, though.

You imply that HTML/XML might use chevrons. I don't think that's the
case. They inherit their start/end tag characters from SGML's
default.

No! That's not what I said.

SGML-derived languages use greater-than and less-than symbols < > as if
they were brackets. That's practicality beats purity: true chevrons are
not available in ASCII or on common keyboards, making them difficult to
use. People commonly call < and > "angle brackets" in the context of HTML
etc. but they aren't really, they are mathematical comparison operator
signs.

Proper chevrons are narrower and taller. The difference between 〈 〉
and < > is *very* obvious in the font I'm using, although of course not
all fonts use the proper glyphs. If it helps, the angle on the inside of
the chevron is about 120 degrees, compared to maybe 60 degrees for the
comparison operators. Again, this depends on the precise glyph being used.

True angle brackets are available in Unicode at code points 9001 and 9002,
(0x2329 and 0x232A). The less-than and greater-than symbols can be found
in both Unicode and ASCII at code points 60 and 62 (0x003C and 0x003E).
I did warn in my earlier post that I was being pedantic. In common usage,
I'll describe <tag> as using angle brackets, just as I'll describe "quote"
as using quote marks. They're not actually: they are double-prime marks,
and ' is a prime mark not an apostrophe or quote mark. Prime and
double-prime marks are also known as foot and inch marks, although *real*
pedants would argue that there is a difference between them too. (I think
they get separate Unicode points.)
It is easy to get confused when it comes to characters, because there are
three separate but related things to keep in mind. Firstly, there is the
glyph or picture used, which differs according to the font and type-style.
Two different glyphs can represent the same symbol, and two identical
glyphs can represent different symbols.

Secondly, there is the semantic meaning of the character: a dash and a
hyphen are both horizontal lines, but they have very different meanings.
Dashes -- sometimes faked with two hyphens in a row like this -- are used
as separators, and hyphens are used to join compound words like
fire-fighting or anti-matter.

Thirdly, there is the specific implementation of the character. ASCII
defines only 127 characters, a good thirty-plus being invisible control
characters. Eight-bit extensions to ASCII unfortunately vary between each
other: the character 176 (0xB0) is the degree symbol in the Latin-1
encoding (ISO 8859-1) but the infinity symbol in the MacRoman encoding.

--
Steven.

[Steve Holden]

Paul McGuire wrote:

"Ben Finney" <bi****************@benfinney.id.au> wrote in message
news:dl**********@rose.polar.local...

Xiao Jianfeng <fd********@gmail.com> wrote:

I need to print a long sting, which is two long so it must expand
two lines.

How is this string being constructed in the source? If it exists as a
single long string, why must it be so long?

Some techniques you may not be aware of:

>>> chunks = ["abc", "def", "ghi"]
>>> s = ''.join(chunks)
>>> print s

abcdefghi

>>> s = "#" * 10
>>> print s

##########

You can, of course, modify the above so that they join or multiply to
create much longer strings.

--
\ "Everything is futile." -- Marvin of Borg |
`\ |
_o__) |
Ben Finney

Or for a large literal string:

"""
lots of text hundreds of characters long
more text on another line but we really don't want any line breaks
in our final string
so we replace newlines in this multiline string
with an empty string thus
""".replace('\n','')

Of course there's also the alternative of escaping the newlines out in
the literal. The replace result above is exactly

"""\
lots of text hundreds of characters long\
more text on another line but we really don't want any line breaks\
in our final string\
so we replace newlines in this multiline string\
with an empty string thus\
"""

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Steve Holden]

Paul McGuire wrote:

"Ben Finney" <bi****************@benfinney.id.au> wrote in message
news:dl**********@rose.polar.local...

Xiao Jianfeng <fd********@gmail.com> wrote:

I need to print a long sting, which is two long so it must expand
two lines.

How is this string being constructed in the source? If it exists as a
single long string, why must it be so long?

Some techniques you may not be aware of:

>>> chunks = ["abc", "def", "ghi"]
>>> s = ''.join(chunks)
>>> print s

abcdefghi

>>> s = "#" * 10
>>> print s

##########

You can, of course, modify the above so that they join or multiply to
create much longer strings.

--
\ "Everything is futile." -- Marvin of Borg |
`\ |
_o__) |
Ben Finney

Or for a large literal string:

"""
lots of text hundreds of characters long
more text on another line but we really don't want any line breaks
in our final string
so we replace newlines in this multiline string
with an empty string thus
""".replace('\n','')

Of course there's also the alternative of escaping the newlines out in
the literal. The replace result above is exactly

"""\
lots of text hundreds of characters long\
more text on another line but we really don't want any line breaks\
in our final string\
so we replace newlines in this multiline string\
with an empty string thus\
"""

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Dave Hansen]

On Tue, 22 Nov 2005 18:38:15 +0000 in comp.lang.python, Steve Holden
<st***@holdenweb.com> wrote:

[...]

Of course there's also the alternative of escaping the newlines out in
the literal. The replace result above is exactly

"""\
lots of text hundreds of characters long\
more text on another line but we really don't want any line breaks\
in our final string\
so we replace newlines in this multiline string\
with an empty string thus\
"""

"""\ That's pretty close, but\
if you don't include spaces at the ends of words\
then Python will run those words\
together, which is probably not what you want."""
"That's pretty close, butif you don't include spaces at the ends of
wordsthen Python will run those wordstogether, which is probably not
what you want." """\ So you need to add spaces, but make sure they're \
before the backslash, and not after."""
"So you need to add spaces, but make sure they're before the
backslash, and not after."

Regards,
-=Dave

--
Change is inevitable, progress is not.

[Steve Holden]

Mohammad Jeffry wrote:

I tried to use this method in my code like this:-
---------------------------------------------------------------------------------
#!/usr/bin/python
def print_sql():
sql = '''aaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbb'''.replace("\n","")
print sql

print_sql()

---------------------------------------------------------------------------------

the ouput of this is aaaaaaaaaaaaaaaa<space><tab>bbbb......

I can always do this :-
---------------------------------------------------------------------------------
#!/usr/bin/python
def print_sql():
sql = '''aaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbb'''.replace("\n","")
print sql

print_sql()

---------------------------------------------------------------------------------

but it looks ugly

[...]
In your particular case, if it really is SQL you're dealing with then
you shouldn't worry about what it looks like when you print it - the SQL
interpreter certainly won't care.

Many SQL statements are so long that it actually helps readability to
have newlines in them.

There have been plenty of solutions presented in the earlier posts in
this thread if you really do need to represent multi-line strings.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Fredrik Lundh]

Mohammad Jeffry wrote:

I can always do this :-
---------------------------------------------------------------------------------
#!/usr/bin/python
def print_sql():
sql = '''aaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbb'''.replace("\n","")
print sql

print_sql()

---------------------------------------------------------------------------------

sql = (
'aaaaaaaaaaaaaaaaaaaaaaa'
'bbbbbbbbbbbbbbbbbbbbbbb'
)
print sql

or, perhaps more realistic:

cursor.execute(
'aaaaaaaaaaaaaaaaaaaaaaa'
'bbbbbbbbbbbbbbbbbbbbbbb',
a, b, c
)

e.g.

cursor.execute(
'select * from foo'
' where bar=%s'
' limit 100',
bar
)
</F>

[Magnus Lycka]

Fredrik Lundh wrote:

cursor.execute(
'select * from foo'
' where bar=%s'
' limit 100',
bar
)

The disavantage with this is that it's easy to make
a mistake, like this...

cursor.execute(
'select * from foo '
'where bar=%s'
'limit 100',
bar
)

That might be a reason to prefer triple quoting instead:

cursor.execute(
'''select * from foo
where bar=%s
limit 100''',
bar
)

This last version will obviously contain some extra whitespace
in the SQL text, and that could possibly have performance
implications, but in general, I prefer to reduce the risk of
errors (and I've made mistakes with missing spaces in adjacent
string literals).

[Fredrik Lundh]

Magnus Lycka wrote:

Fredrik Lundh wrote:

cursor.execute(
'select * from foo'
' where bar=%s'
' limit 100',
bar
)
The disavantage with this is that it's easy to make
a mistake, like this...

cursor.execute(
'select * from foo '
'where bar=%s'
'limit 100',
bar
)

that's why I prefer to put the spaces first. if you do that, you'll spot
the mistakes immediately.

(on the other hand, the chance that the SQL engine won't notice this
typo is pretty slim).
That might be a reason to prefer triple quoting instead:

cursor.execute(
'''select * from foo
where bar=%s
limit 100''',
bar
)
"but it looks ugly"

(as usual, threads like this goes round and round and round ;-)
This last version will obviously contain some extra whitespace
in the SQL text, and that could possibly have performance
implications, but in general, I prefer to reduce the risk of
errors (and I've made mistakes with missing spaces in adjacent
string literals).

absolutely. but if you don't want newlines and whitespace in your
strings, using auto-catenated plain literals is a good alternative, at
least if you combine with a little indentation discipline.

</F>