views:

376

answers:

3

How would you go about formatting a long line such as this? I'd like to get it to no more than 80 characters wide:

logger.info("Skipping {0} because its thumbnail was already in our system as {1}.".format(line[indexes['url']], video.title))

Is this my best option?

url = "Skipping {0} because its thumbnail was already in our system as {1}."
logger.info(url.format(line[indexes['url']], video.title))
+7  A: 

Consecutive string literals are joined by the compiler, and parenthesized expressions are considered to be a single line of code:

logger.info("Skipping {0} because it's thumbnail was "
  "already in our system as {1}.".format(line[indexes['url']],
  video.title))
Ignacio Vazquez-Abrams
+3  A: 

Personally I dislike hanging open blocks, so I'd format it as:

logger.info(
    'Skipping {0} because its thumbnail was already in our system as {1}.'
    .format(line[indexes['url']], video.title)
)

In general I wouldn't bother struggle too hard to make code fit exactly within a 80-column line. It's worth keeping line length down to reasonable levels, but the hard 80 limit is a thing of the past.

bobince
It's not really a thing of the past. The Python standard library still uses PEP8 as its style guide, so the rule still exists, and plenty of people (myself included) follow it. It's a convenient place to draw the line.
Devin Jeanpierre
I wonder how many projects still follow the 80 char rule. For the average window size I use, I think 100-120 is more productive for me than 80 chars.
Gattster
Yes, that's about the line length I use too, though [horror! sacrilege!] I use a proportional font, so exact line length isn't so critical. It's more a case of how much logic on a single line is readable than how many characters, as such... if I've got a long string of data that no-one needs to read I'm happy to let it spill over 120.
bobince
Proportional fonts for code - I'm with you, brother. Judging by the distaste everyone I've ever worked with have had for them though, the world ain't ready.
jlarcombe
+3  A: 

That's a start. It's not a bad practice to define your longer strings outside of the code that uses them. It's a way to separate data and behavior. Your first option is to join string literals together implicitly by making them adjacent to one another:

("This is the first line of my text, "
"which will be joined to a second.")

Or with line ending continuations, which is a little more fragile, as this works:

"This is the first line of my text, " \
"which will be joined to a second."

But this doesn't:

"This is the first line of my text, " \ 
"which will be joined to a second."

See the difference? No? Well you won't when it's your code either.

The downside to implicit joining is that it only works with string literals, not with strings taken from variables, so things can get a little more hairy when you refactor. Also, you can only interpolate formatting on the combined string as a whole.

Alternatively, you can join explicitly using the concatenation operator (+):

("This is the first line of my text, " + 
"which will be joined to a second.")

Explicit is better than implicit, as the zen of python says, but this creates three strings instead of one, and uses twice as much memory: there are the two you have written, plus one which is the two of them joined together, so you have to know when to ignore the zen. The upside is you can apply formatting to any of the substrings separately on each line, or to the whole lot from outside the parentheses.

Finally, you can use triple-quoted strings:

"""This is the first line of my text
which will be joined to a second."""

This is often my favorite, though its behavior is slightly different as the newline and any leading whitespace on subsequent lines will show up in your final string. You can eliminate the newline with an escaping backslash.

"""This is the first line of my text \
which will be joined to a second."""

This has the same problem as the same technique above, in that correct code only differs from incorrect code by invisible whitespace.

Which one is "best" depends on your particular situation, but the answer is not simply aesthetic, but one of subtly different behaviors.

jcdyer
The CPython compiler optimizes out literal operations as much as possible, which means that adding two string literals results in only a single string literal in the bytecode.
Ignacio Vazquez-Abrams
While all of the answers I've received are helpful, yours definitely helps me understand all of the ways to break strings up. Was the problem with the "\" line ending that there was a space after it?
Gattster
I can't see the difference here, but then, that's mostly because of SO's rather primitive syntax coloring. (Some perfectly good code is virtually unreadable on SO, but only because it's not in a language whose syntax is very close to C.) It's not unusual to make your editor obnoxiously highlight trailing spaces, since they're rarely useful (or intentional). :-)
Ken
@Gattster -- Yup. You caught it. It shows up when you select the text. And yeah, good text editors/IDEs can help with that.
jcdyer