pprint produces invalid output for long strings

[serhiy-storchaka]

BPO	19104
Nosy	@freddrake, @pitrou, @bitdancer, @serhiy-storchaka
Files	pprint_str_evaluable.patch: Use backslashes pprint_str_evaluable_2.patch: Use parentheses

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/serhiy-storchaka'
closed_at = <Date 2014-12-20.19:44:15.257>
created_at = <Date 2013-09-27.13:40:50.957>
labels = ['easy', 'type-bug', 'library']
title = 'pprint produces invalid output for long strings'
updated_at = <Date 2014-12-20.19:44:15.228>
user = 'https://github.com/serhiy-storchaka'

bugs.python.org fields:

activity = <Date 2014-12-20.19:44:15.228>
actor = 'serhiy.storchaka'
assignee = 'serhiy.storchaka'
closed = True
closed_date = <Date 2014-12-20.19:44:15.257>
closer = 'serhiy.storchaka'
components = ['Library (Lib)']
creation = <Date 2013-09-27.13:40:50.957>
creator = 'serhiy.storchaka'
dependencies = []
files = ['31886', '31887']
hgrepos = []
issue_num = 19104
keywords = ['patch', 'easy', 'needs review']
message_count = 15.0
messages = ['198474', '198478', '198480', '198488', '198491', '198492', '198494', '198502', '198666', '198667', '198668', '206271', '232416', '232978', '232981']
nosy_count = 6.0
nosy_names = ['fdrake', 'pitrou', 'Arfrever', 'r.david.murray', 'python-dev', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue19104'
versions = ['Python 3.4', 'Python 3.5']

[serhiy-storchaka]

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 bpo-17150 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 '

[bitdancer]

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

[serhiy-storchaka]

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.

[pitrou]

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.

[serhiy-storchaka]

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

[pitrou]

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

[serhiy-storchaka]

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.

[pitrou]

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

[serhiy-storchaka]

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.

[pitrou]

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

[serhiy-storchaka]

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

[BreamoreBoy]

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

[serhiy-storchaka]

What to do with this issue?

[python-dev]

New changeset 872f048f0403 by Serhiy Storchaka in branch '3.4':
Issue bpo-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 bpo-19104: pprint now produces evaluable output for wrapped strings.
https://hg.python.org/cpython/rev/4d3066d4a5df

[serhiy-storchaka]

Thank you Antoine for your review.