The documentation says: """The pprint module provides a capability to “pretty-print” arbitrary Python data structures in a form which can be used as input to the interpreter.""" But #since issue17150 long lines are splitted on shorter lines without continuation character and the result can't be used as input to the interpreter. >>> pprint.pprint('abc '*20) 'abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc '\ 'abc '

FYI this defect was mentioned (by Antoine) in Issue17530, though that issue is about bytes.

Thank you David. In any case this is worth a separate issue. Here is a patch. Personally I prefer to add continuation backslash even for inner wrapped lines, but I'm not sure that most core developers will agreed with it.

According to PEP 8, parentheses should be used for multi-line expressions, not backslashes: """The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in parentheses. These should be used in preference to using a backslash for line continuation.""" Also, please note that in both cases it adds a character to the lines, which must be taken into account in the algorithm.

Second path uses parentheses. It is more complicated than first patch. I prefer first patch, because it is simple, because second variant wastes more width, because parentheses looks too similar to tuple, and because "implicit string literal concatenation considered harmful"[1]. http://comments.gmane.org/gmane.comp.python.ideas/20525

> "implicit string literal concatenation considered harmful" Both patches rely on implicit string literal concatenation. Another possibility is not fixing this issue, and deciding it is normal behaviour. It is trivial to add parentheses if you need them.

> Both patches rely on implicit string literal concatenation. But with backslash it *looks* less implicit. > Another possibility is not fixing this issue, and deciding it is normal behaviour. It is trivial to add parentheses if you need them. It would be safer just do not wrap long line on first level.

> > Another possibility is not fixing this issue, and deciding it is > normal behaviour. It is trivial to add parentheses if you need them. > > It would be safer just do not wrap long line on first level. That would defeat the whole point of pprint().

The whole point of pprint() is formatted output of containers such as list or dict. Before 3.4 it does not wrap long strings at all. Of course I don't think this alternative is good. But at least it is better than producing illegal output.

> The whole point of pprint() is formatted output of containers such as > list or dict. Well, the whole point of pprint is pretty-printing. Being restricted to containers is a bug, not a feature...

I doubt we are able to fix it in maintained releases.

Would it pay to have a meta issue for all the outstanding pprint issues, or possibly make issue 7434 the meta issue?

What to do with this issue?

New changeset 872f048f0403 by Serhiy Storchaka in branch '3.4': Issue #19104: pprint now produces evaluable output for wrapped strings. https://hg.python.org/cpython/rev/872f048f0403 New changeset 4d3066d4a5df by Serhiy Storchaka in branch 'default': Issue #19104: pprint now produces evaluable output for wrapped strings. https://hg.python.org/cpython/rev/4d3066d4a5df

Thank you Antoine for your review.