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]

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

 

[Lars Kellogg-Stedman]

print "a string whcih is very very looooooooooooooooooooooooooooooooooo\

oooooooooooooooooooong."

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

-- Lars

 

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

Xiao Jianfeng wrote:


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.

 

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

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

 

[Xiao Jianfeng]

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

-- Lars

Oh, Thank you!

 

[Ben Finney]

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

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

 

[Tony Nelson]

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.
[/QUOTE]

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]

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

 

[Alex Martelli]

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

 

[Bengt Richter]

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

 

[Steven D'Aprano]

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.

 

[Mike Meyer]

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

 

[Steven D'Aprano]

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.

 

[Paul McGuire]

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','')

-- Paul

 

[Steve Holden]

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]

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

 

[Dave Hansen]

On Tue, 22 Nov 2005 18:38:15 +0000 in comp.lang.python, Steve Holden

[...]

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