If a piece of text given to textwrap contains one or more "\n", textwrap
does not break at that point. I would have expected "\n" characters to
cause forced breaks.

Attaching a patch that corrects the issue  (against python 2.4)

Could you give an example showing the unexpected behaviour, and 
describing what behaviour you'd expect, please?

As far as I can tell, the patch has no effect on textwrap.wrap or 
textwrap.fill, since any newlines have already been converted to spaces 
by the time the _wrap_chunks method is called.

Thanks.

If replace_whitespace in textwrap is set to False (True is default) then
there are newlines. Yes, if you haven't set this then the patch does
nothing (but that sounds sane to me)

The exact text was "RadioTest TOSSIM stress tester by Tom Parker
<t.e.v.parker@tudelft.nl>\nKeeps running TOSSIM with random seeds until
something fails", which with a width of 78 gets broken both before and
after the "Keeps".

The original behavior is intentional. Please don't attempt to "fix" it.

Is there any other way to do what I was trying to do then (both dynamic
wrapping for long segments + some static breaks)? Right now, the only
option I can think of is writing a textwrap.TextWrapper subclass that
implements my patch, and copying 70-ish lines of code to make a 2 line
change seems like overkill to me. Could this be added as a new option to
TextWrapper?

Use .splitlines() to break the input into lines, wrap each "line"
separately, and join again?

For what it's worth, I think there is a legitimate complaint here, though it was initially 
unclear to me exactly what that complaint was.  Consider the following:

>>> from textwrap import *
>>> T = TextWrapper(replace_whitespace=False, width=14)
>>> for line in T.wrap('one two\nthree four'): print line
... 
one two
three
four

The surprise (if I understand correctly) is not the first line break, but the second, between 
"three" and "four":  it shouldn't be necessary, since "three four" fits quite happily on a 
line of length 14.

@Guido: Thanks for the suggestion, it fixes my immediate problem!
@Mark: Yup, that was exactly my issue. It took a while to figure out why
the heck it was ignoring my linebreaks, and then once I'd found
replace_whitespace it appeared to be doing the "wrong" thing to me.

I'm still for the changing of the behaviour to what I expected, but I
can live with this otherwise. Documenting that this is the behaviour in
the textwrap docs, and suggesting workarounds for those who want the
other choice might be a good idea tho.

Mark, it looks like the replace_whitespace flag shouldn't be used with
input containing newlines.

Is it worth double checking with Greg Ward that this behaviour really is 
intentional?

Good luck reaching him.

I'm pretty sure that the default behavior intentional *reflows* all
input text.  Perhaps you can derive clues from reading the docs (which I
haven't)?

This bug should be re-opened, since there is definitely a bug here.  
I think the patch was incorrectly rejected.

If I can expand palfrey's example:

from textwrap import *
T = TextWrapper(replace_whitespace=False, width=75)
text = '''\
aaaaa aaaaa aaaaa aaaaa aaaaa
bbbbb bbbbb bbbbb bbbbb bbbbb
ccccc ccccc ccccc ccccc ccccc
ddddd ddddd ddddd ddddd ddddd
eeeee eeeee eeeee eeeee eeeee'''
for line in T.wrap(text): print line

Python 2.5 textwrap turns it into:

aaaaa aaaaa aaaaa aaaaa aaaaa
bbbbb bbbbb bbbbb bbbbb bbbbb
ccccc ccccc
ccccc ccccc ccccc
ddddd ddddd ddddd ddddd ddddd
eeeee eeeee eeeee eeeee
eeeee

That can't be right.  palfrey's patch leaves the input unchanged, which 
seems correct to me.  I think Guido guessed wrong here: the docs for 
replace_whitespace say:

  If true, each whitespace character (as defined by string.whitespace)
  remaining after tab expansion will be replaced by a single space

The text should therefore not be reflowed in this case since 
replace_whitespace=False.  palfrey's patch seems correct to me.

It can be made to reflow to the full width by editing palfrey's patch, 
but that would disagree with the docs and break code.

I think the code originally wasn't meant to support this feature (honor 
embedded newlines when replace_whitespace=False). I'm thinking that we 
could add it though.  Maybe Mark is interested in getting this into 2.7 
and 3.2?  I imagine it needs a new unittest too.

I'll take a look.

I agree that if newlines in the text are left in, they should reset the
characters in line count to 0 the same as inserted newlines.

I notice that Greg Ward just resurfaced on the issue tracker (issue 6454).  
:)

Greg, any comment on this issue?

The current patch is too simple:  it fails if lines end with ' \n', for 
example.  The simplest way to make this work may be to put each '\n' into 
its own chunk.

> Greg, any comment on this issue?

Yes, two:

1) textwrap does not handle paragraphs or paragraph breaks in any way.  
That was a deliberate limitation to keep the code from getting any 
hairier.  People have complained about this in the past, and I have 
studiously ignored such complaints.  The standard answer is that you 
should break your text into paragraphs and then feed those paragraphs 
individually to a TextWrapper.  But this does not look like that old 
complaint.

2) Test, test, test.  In case you hadn't already noticed, this is a 
hairy piece of code.  It's also a poster child for unit testing.  Any 
change should IMHO be accompanied by lots of new tests.

No wait, make that *three* comments:

3) I agree with tlynn that the example in msg95469 looks *awfully* 
fishy.  But I don't remember enough of the details to say what's likely 
to be broken.  That's probably your first test case right there.

As a temporary workaround, you can use the `wrap` function in my strnum
module (http://pypi.python.org/pypi/strnum/2.4).

Phillip

Thanks for the feedback, Greg!

I'm afraid I'm unassigning this;  I don't have time for it right now, and 
I'm not sure I'm the right person to do this anyway.

One problem that I was having when I looked at this:  I don't think I 
understand what the intended use of replace_whitespace=False is in the 
first place.  Given that a typical piece of (English) text only contains 
the ' ', '\t' ad '\n' whitespace characters, if expand_tabs is True (the 
default), then it seems that newline characters are the only ones affected 
by replace_whitespace=False.

How is replace_whitespace=False expected to be used currently?

Anyone interested in picking this up?  I've tried and fell flat on my face :(

The weird behaviour is caused by newlines being treated as normal whitespace characters and not actually causing _wrap_chunks() to break the line. This means that it builds "lines" of up to 'width' characters which may contain newlines:

>>> text = '''\
... aaa aaa aaa
... bbb bbb bbb
... ccc ccc ccc
... ddd ddd ddd'''
>>> T = TextWrapper(replace_whitespace=False, width=17)    
>>> T.wrap(text)
['aaa aaa aaa\nbbb', 'bbb bbb\nccc ccc', 'ccc\nddd ddd ddd']
>>> for line in T.wrap(text): print(line)
... 
aaa aaa aaa
bbb
bbb bbb
ccc ccc
ccc
ddd ddd ddd

There's no clean way to deal with this inside _wrap_chunks() (as Greg implied), so I think we should just document the existing behaviour and recommend the splitlines() workaround.

It might be useful to add a wrap_paragraphs() convenience function that does the split/wrap/join, but I don't think that would add enough value to be worth the change.

Here's a doc patch for py3k. A similar patch for 2.7 (and other versions?) might be a good idea.

+1 for applying the doc patch.

I'd be interested in having a go if I knew what the desired behaviour was, ie unit tests to confirm what was 'correct'.

How should it handle line breaks? Should it treat them like any other whitespace as at present, should it honour them, or should it get another option, eg 'honor_breaks' (if US spelling is the standard for Python's libraries)?

Georg, if your comment means that you think that the doc patch is ready to apply, as is, without testing with a doc build, then I will do so for all 3 versions.

Should there really be two blank lines after the note?

Yes, please do apply.  You don't need to run a doc build for every small change; of course it is nice if you do, but errors will be caught by the daily build routine anyway and mailed to me.

As for the two blank lines: you'll see that the original conversion from LaTeX produced two blank lines after each description (function, class, ...), and I find this to be a little more readable than only one blank line, especially when the descriptions are longer; for short descriptions leaving only one blank line saves space.  Syntactically, both are fully equivalent.

I would like to unsubscribe from this thread, but haven't been able to
figure out how to do it.

Phillip

On Mon, Nov 22, 2010 at 11:50 PM, Georg Brandl <report@bugs.python.org>wrote:

>
> Georg Brandl <georg@python.org> added the comment:
>
> Yes, please do apply.  You don't need to run a doc build for every small
> change; of course it is nice if you do, but errors will be caught by the
> daily build routine anyway and mailed to me.
>
> As for the two blank lines: you'll see that the original conversion from
> LaTeX produced two blank lines after each description (function, class,
> ...), and I find this to be a little more readable than only one blank line,
> especially when the descriptions are longer; for short descriptions leaving
> only one blank line saves space.  Syntactically, both are fully equivalent.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1859>
> _______________________________________
>

textwrap_2010-11-23.diff is my attempt to provide a fix, if it's wanted/needed.

Doc patch applied to 3.2, 3.1, 2.7 in r86717, r86718, r86719
Jeremy Thurgood added to 3.2 Misc/ACKS in r86720.
(I know, I should have added this first before committing.)

I am leaving this open for a possible behavior patch.

Mathew: look at the examples by Tom Lynn and Jeremy Thurgood for unit tests. My comment "If newlines in the text are left in, [with replace_whitespace=False] they should reset the
characters-in-line count to 0 the same as inserted newlines." may be all that is needed for a fix.

If and when there is a behavior patch, the current doc patch should be reverted (undone) with an alternate doc patch.

Whoops, you just added a patch while I wrote the above. I will try to take a look if no one else does.

I've also been attempting to look into this and came up with an almost identical patch, which is promising:
https://bitbucket.org/tlynn/issue1859/diff/textwrap.py?diff2=041c9deb90a2&diff1=f2c093077fbf

I missed the wordsep_simple_re though.

Testing it is the hard part.  I've got a few examples that could become tests in that repository, but it's far from conclusive.

One corner case I found is trailing whitespace becoming a blank line:

>>> from textwrap import TextWrapper
>>> T = TextWrapper(replace_whitespace=False, drop_whitespace=False, width=9)
>>> T.wrap('x'*9 + ' \nfoo')
['xxxxxxxxx', ' ', 'foo']

I think it's fine.  drop_whitespace=True removes the blank line, and those who really want drop_whitespace=False can remove the blank lines easily.

As a note to comments msg60038-msg60040, for anybody like me who ended up here after Googling around on how to do wordwrap in Python:

The function textwrap in Python is for single strings/paragraphs only, and it does not work as wordwrap normally works in text editors or other programming languages (eg. Wordwrap in Python).


If you want to do wordwrap or a block of text, run something like this:

new_msg = ""
lines = msg.split("\n")

for line in lines:
    if len(line) > 75:
        w = textwrap.TextWrapper(width=75, break_long_words=False)
        line = '\n'.join(w.wrap(line))

    new_msg += line + "\n"

An use case example for this would be, if you have a email message and you want to apply word wrapping to it, so that no line would be over 78 characters.

In previous comment: (eg. Wordwrap in Python) -> (wordwrap() in PHP)

Some examples of how this function works on text blocks:

Original text:

--
*Maksaako riippuvuus yksittäisestä ohjelmistoyritykstä Helsingille vuosittain 3,4 miljoonaa euroa?*


Helsingin kaupungin raportti OpenOffice-pilottihankkeesta tuottaa kaupunkilaisille enemmän kysymyksiä kuin vastauksia. Kaupunki kokeili avoimen lähdekoodin hyötyohjelmistopakettia kaupunginvaltuuston jäsenten kannettavissa tietokoneissa kymmenen kuukauden ajan vuonna 2011. Ohjelmistopaketti sai käyttäjiltä laajan hyväksynnän. Kokeilun päätyttyä kaupunki tuotti pilotista raportin, jonka mukaan OpenOfficen käyttöönotto koko virkamieskunnalle tulisi hyvin kalliiksi.

"Kaupungin raportti väittää, että maksaisi 3,4 miljoonaa euroa vuodessa käyttää OpenOfficea. Luku vaikuttaa yllättävän isolta ja raportti ei selosta, miten lukuun on päädytty," sanoo Otto Kekäläinen, Euroopan vapaiden ohjelmien säätiö (Free Software Foundation Europe, FSFE), Suomen paikalliskoordinaattori. "Ilman tarkkoja tietoja, luku vaikuttaa perusteettomalta." Ilmeisesti Helsingin hallinto ei raporttia laatiessaan edes ollut yhteydessä yleisiin OpenOffice-palveluiden tarjoajiin tiedustellaakseen hintoja.
--

Applying
msg.message_body = textwrap.fill(msg.message_body_unwrapped, 75)

--
 *Maksaako
riippuvuus yksittäisestä ohjelmistoyritykstä Helsingille vuosittain
3,4 miljoonaa euroa?*   Helsingin kaupungin raportti OpenOffice-
pilottihankkeesta tuottaa kaupunkilaisille enemmän kysymyksiä kuin
vastauksia. Kaupunki kokeili avoimen lähdekoodin
hyötyohjelmistopakettia kaupunginvaltuuston jäsenten kannettavissa
tietokoneissa kymmenen kuukauden ajan vuonna 2011. Ohjelmistopaketti
sai käyttäjiltä laajan hyväksynnän. Kokeilun päätyttyä
kaupunki tuotti pilotista raportin, jonka mukaan OpenOfficen
käyttöönotto koko virkamieskunnalle tulisi hyvin kalliiksi.
"Kaupungin raportti väittää, että maksaisi 3,4 miljoonaa euroa
vuodessa käyttää OpenOfficea. Luku vaikuttaa yllättävän isolta
ja raportti ei selosta, miten lukuun on päädytty," sanoo Otto
Kekäläinen, Euroopan vapaiden ohjelmien säätiö (Free Software
Foundation Europe, FSFE), Suomen paikalliskoordinaattori. "Ilman
tarkkoja tietoja, luku vaikuttaa perusteettomalta." Ilmeisesti
Helsingin hallinto ei raporttia laatiessaan edes ollut yhteydessä
yleisiin OpenOffice-palveluiden tarjoajiin tiedustellaakseen hintoja.
--


Applying
msg.message_body = textwrap.fill(msg.message_body_unwrapped, 75, break_long_words=False, replace_whitespace=False)

--
*Maksaako
riippuvuus yksittäisestä ohjelmistoyritykstä Helsingille vuosittain
3,4 miljoonaa euroa?*


Helsingin kaupungin raportti OpenOffice-
pilottihankkeesta tuottaa kaupunkilaisille enemmän kysymyksiä kuin
vastauksia. Kaupunki kokeili avoimen lähdekoodin
hyötyohjelmistopakettia kaupunginvaltuuston jäsenten kannettavissa
tietokoneissa kymmenen kuukauden ajan vuonna 2011. Ohjelmistopaketti
sai käyttäjiltä laajan hyväksynnän. Kokeilun päätyttyä
kaupunki tuotti pilotista raportin, jonka mukaan OpenOfficen
käyttöönotto koko virkamieskunnalle tulisi hyvin kalliiksi.
"Kaupungin raportti väittää, että maksaisi 3,4 miljoonaa euroa
vuodessa käyttää OpenOfficea. Luku vaikuttaa yllättävän isolta
ja raportti ei selosta, miten lukuun on päädytty," sanoo Otto
Kekäläinen, Euroopan vapaiden ohjelmien säätiö (Free Software
Foundation Europe, FSFE), Suomen paikalliskoordinaattori. "Ilman
tarkkoja tietoja, luku vaikuttaa perusteettomalta." Ilmeisesti
Helsingin hallinto ei raporttia laatiessaan edes ollut yhteydessä
yleisiin OpenOffice-palveluiden tarjoajiin tiedustellaakseen hintoja.
--

In case this bug report form wraps the text, you can also view the it at pastebin: http://pastebin.com/y6icAJC6

Cooking recipe for Otto:

def wrap_paragraphs(text, width=70, **kwargs):
    return [line for para in text.splitlines() for line in textwrap.wrap(para, width, **kwargs)]

Here is an even simpler failing test case:

>>> from textwrap import wrap
>>> wrap("a\nb", replace_whitespace=False)
['a\nb']

It should return--

['a', 'b']

I will start working on this issue by assembling formal test cases.

> def wrap_paragraphs(text, width=70, **kwargs):
>     return [line for para in text.splitlines() for line in textwrap.wrap(para, width, **kwargs)]

I just want to point out that, at least for the purposes of this issue, I don't believe the above is equivalent to what we want.  For example--

>>> wrap_paragraphs('a\n\nb', replace_whitespace=False)
['a', 'b']

With replace_whitespace=False, we want to preserve newline information, which would instead mean a return value of--

['a', '', 'b']

def wrap_paragraphs(text, width=70, **kwargs):
    return [line for para in text.splitlines() for line in textwrap.wrap(para, width, **kwargs) or ['']]

In working on the patch for this issue, I also noticed that there is a minor error in the documentation of the replace_whitespace attribute.

The docs say that string.whitespace is used, but the code uses a hard-coded string and includes a comment explaining why string.whitespace should *not* be used.

http://hg.python.org/cpython/file/1102e86b8739/Lib/textwrap.py#l30

I will correct this in the patch, but if people think so, I could file it as a separate issue.

Sorry, that link should have been--

http://hg.python.org/cpython/file/1d811e1097ed/Lib/textwrap.py#l12

(hg.python.org seems to default to the 2.7 branch.  I just filed an issue about this.)

If people are interested, I filed a new issue (issue 15492) about textwrap's tab expansion that I noticed while working on this issue.

Marking issue 15510 as a dependency because there is a behavioral issue in existing use cases that affects how to proceed in this issue.

After discussing issue15510, I think this should probably be left as-is, or be implemented in a separate function so as to avoid breaking compatibility.

> After discussing issue15510, I think this should probably be left as-is, or be implemented in a separate function so as to avoid breaking compatibility.

Note that this issue can be addressed without affecting backwards compatibility in the documented supported cases.  textwrap.wrap()'s documentation says that it only supports single paragraph input and even warns against "strange output" otherwise.

Also, as Mark pointed out above, what use case does replace_whitespace=False have if this issue is not addressed?

http://bugs.python.org/issue1859#msg96064

Addressing this issue would give that argument meaning (for multi-paragraph input).

Finally, just to be clear, I marked issue 15510 as a dependency in the sense that I felt it should be decided before addressing this issue -- not that the issue needed to be addressed in the affirmative.

I believe that the method of work with newlines is too application specific.

Someone may prefer empty line separated paragraphs, here is another recipe:

def wrap_paragraphs(text, width=70, **kwargs):
    return [line for para in re.split(r'\n\s*\n', text) for line in (textwrap.wrap(para, width, **kwargs) + [''])][:-1]

And here is another application-specific recipe:

def format_html_paragraphs(text, width=70, **kwargs):
    return ''.join('<p>%s</p>' % '<br>'.join(textwrap.wrap(html.escape(para), width, **kwargs)) para in re.split(r'\n\s*\n', text))

I don't see a one obvious way to solve this problem, so I suggest a recipe, not a patch. In any case the specialized text-processing applications are not likely to use textwrap because most output now uses non-monowidth fonts. Textwrap is only for the simplest applications.

applied patches textwrap_2010-11-23.diff and issue1859_docs.diff
added line_break tests