Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Building a multiline string

1 view
Skip to first unread message

lallous

unread,
Feb 4, 2010, 6:34:04 AM2/4/10
to
Hello

Maybe that's already documented, but it seems the parser accepts to
build a long string w/o really using the first method:

# Method1
x = "line1" + \ # cannot use comments!
"line2"+ \
"line3"

and instead using a list with one element like this:

# Method2
x = [
"line1" # can use comments
"line2"
"line3"
][0]

Or:
# Method3
x = (
"line1" # can use comments
"line2"
"line3"
)

(Not that I don't want new lines in the strings)

Now should I be using method 2 or 3 in production code?

--
Elias

Ulrich Eckhardt

unread,
Feb 4, 2010, 7:09:46 AM2/4/10
to
Just for the record: Neither of the below methods actually produce a
multiline string. They only spread a string containing one line over
multiple lines of source code.

lallous wrote:
> Maybe that's already documented, but it seems the parser accepts to
> build a long string w/o really using the first method:
>
> # Method1
> x = "line1" + \ # cannot use comments!
> "line2"+ \
> "line3"

Well, obviously you can't use comments like that there. The point of the
backslash is that it continues the current logical line over the
_immediately_ _following_ newline. If anything follows, that obviously
doesn't work.

> and instead using a list with one element like this:
>
> # Method2
> x = [
> "line1" # can use comments
> "line2"
> "line3"
> ][0]

This basically makes use of the fact that "this" "is" "one" "string" and not
four strings.

> # Method3
> x = (
> "line1" # can use comments
> "line2"
> "line3"
> )

This uses the same, only that this time it uses brackets which cause an
expression to extend to multiple lines.

> (Not that I don't want new lines in the strings)

You don't not want or you don't want newlines? Depending on that, you could
also do this:

# method 4
x = "line1"\
"line2"\
"line3"

or maybe

# method 5
x = """line1
line2
line3
"""


> Now should I be using method 2 or 3 in production code?

I'd go for 3 or 4. 2 is basically a hack (you could do the same with a
dictionary, or a tuple, not only a list). 1 will actually create strings
and then concatenate them (unless Python is smart enough to optimize that),
but it allows adding expressions in the middle.

Uli

--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

Steve Holden

unread,
Feb 4, 2010, 7:31:01 AM2/4/10
to pytho...@python.org
I should have thought it was pretty obvious that method 2 creates a list
and then performs an indexing operation on it. These are completely
unnecessary operations, which are avoided in method 3 which is a simple
parenthesised expression.

So why anyone would want to adopt method 2, which is also mess clear as
source code, is beyond me.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

Marco Mariani

unread,
Feb 4, 2010, 8:23:46 AM2/4/10
to
On 02/04/2010 12:34 PM, lallous wrote:

> Now should I be using method 2 or 3 in production code?

Another way... depending on what you are using the string for, of
course. If it's an HTML/XML/SQL/whatever piece of code:

>>>> from textwrap import dedent
>>>> sql = dedent("""
> ... SELECT *
> ... FROM table
> ... WHERE foo=bar
> ... """)
>>>>
>>>> print sql
>
> SELECT *
> FROM table
> WHERE foo=bar
>


And if you don't want the starting/ending newlines:

>>>> sql = dedent("""\
> ... SELECT *
> ... FROM table
> ... WHERE foo=bar\
> ... """)
>>>>
>>>> print sql
> SELECT *
> FROM table
> WHERE foo=bar
>>>>

I use this sometimes to keep both python and the embedded code readable
while preserving indentation.


Duncan Booth

unread,
Feb 4, 2010, 1:23:35 PM2/4/10
to
lallous <lal...@lgwm.org> wrote:

> Now should I be using method 2 or 3 in production code?

Also Method1a:

# Method1a
x = ("line1" + # can use comments!
"line2"+
"line3")

Use Method1a or Method3 as you prefer: either of these generates a single
string constant. Method2 is dumb.

lallous

unread,
Feb 5, 2010, 6:11:01 AM2/5/10
to
@Ulrich:

On Feb 4, 1:09 pm, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
> Just for the record: Neither of the below methods actually produce a
> multiline string. They only spread a string containing one line over
> multiple lines of source code.
>

I meant:
"Note" -> "Note: I don't want to use new lines"

I did not want a multi line string


Thanks guys, method 3 seems to be good enough.

Aahz

unread,
Feb 8, 2010, 6:24:01 PM2/8/10
to
In article <cd36d2f3-fdd0-4dd0...@l26g2000yqd.googlegroups.com>,

lallous <lal...@lgwm.org> wrote:
>
>x = (
>"line1" # can use comments
>"line2"
>"line3"
>)

You should indent the second and following lines (I changed the name to
"xyz" to make clear that the following lines use a regular Python indent
rather than lining up under the open paren):

xyz = (


"line1" # can use comments
"line2"
"line3"
)

--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

import antigravity

0 new messages