This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: textwrap doesn't linebreak on "\n"
Type: enhancement Stage: test needed
Components: Library (Lib) Versions: Python 3.2
process
Status: open Resolution:
Dependencies: 15510 Superseder:
Assigned To: Nosy List: chris.jerdonek, dbudinova, georg.brandl, gvanrossum, gward, jcea, jerith, mark.dickinson, mrabarnett, otto, palfrey, paul.j3, pitrou, r.david.murray, serhiy.storchaka, terry.reedy, tlynn
Priority: normal Keywords: patch

Created on 2008-01-17 12:40 by palfrey, last changed 2022-04-11 14:56 by admin.

Files
File name Uploaded Description Edit
textwrap-fix.patch palfrey, 2008-01-17 12:46 Patch for the issue
issue1859_docs.diff jerith, 2010-11-20 15:24 review
textwrap_2010-11-23.diff mrabarnett, 2010-11-23 20:19
line_break_tests.patch dbudinova, 2014-03-19 15:15 tests for linebreak on "\n" review
Messages (46)
msg60026 - (view) Author: Tom Parker (palfrey) Date: 2008-01-17 12:40
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.
msg60027 - (view) Author: Tom Parker (palfrey) Date: 2008-01-17 12:46
Attaching a patch that corrects the issue  (against python 2.4)
msg60031 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-01-17 15:24
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.
msg60032 - (view) Author: Tom Parker (palfrey) Date: 2008-01-17 15:51
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".
msg60038 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-01-17 17:51
The original behavior is intentional. Please don't attempt to "fix" it.
msg60039 - (view) Author: Tom Parker (palfrey) Date: 2008-01-17 18:03
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?
msg60040 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-01-17 18:14
Use .splitlines() to break the input into lines, wrap each "line"
separately, and join again?
msg60042 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-01-17 18:16
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.
msg60043 - (view) Author: Tom Parker (palfrey) Date: 2008-01-17 18:23
@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.
msg60045 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-01-17 18:26
Mark, it looks like the replace_whitespace flag shouldn't be used with
input containing newlines.
msg60047 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-01-17 18:39
Is it worth double checking with Greg Ward that this behaviour really is 
intentional?
msg60048 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-01-17 18:40
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)?
msg95469 - (view) Author: Tom Lynn (tlynn) Date: 2009-11-19 13:52
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.
msg95483 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2009-11-19 15:56
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.
msg95547 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-20 14:17
I'll take a look.
msg95562 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2009-11-20 20:38
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.
msg95797 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-28 18:33
I notice that Greg Ward just resurfaced on the issue tracker (issue 6454).  
:)

Greg, any comment on this issue?
msg95798 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-28 18:47
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.
msg95800 - (view) Author: Greg Ward (gward) (Python committer) Date: 2009-11-28 22:11
> 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.
msg95831 - (view) Author: Phillip M. Feldman (Phillip.M.Feldman@gmail.com) Date: 2009-11-30 06:58
As a temporary workaround, you can use the `wrap` function in my strnum
module (http://pypi.python.org/pypi/strnum/2.4).

Phillip
msg96064 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-12-07 18:51
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?
msg116915 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-09-20 07:42
Anyone interested in picking this up?  I've tried and fell flat on my face :(
msg121658 - (view) Author: Jeremy Thurgood (jerith) Date: 2010-11-20 14:47
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.
msg121663 - (view) Author: Jeremy Thurgood (jerith) Date: 2010-11-20 15:24
Here's a doc patch for py3k. A similar patch for 2.7 (and other versions?) might be a good idea.
msg121914 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-11-21 12:37
+1 for applying the doc patch.
msg122189 - (view) Author: Matthew Barnett (mrabarnett) * (Python triager) Date: 2010-11-23 02:31
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)?
msg122196 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-11-23 06:59
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?
msg122200 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-11-23 07:50
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.
msg122222 - (view) Author: Phillip M. Feldman (Phillip.M.Feldman@gmail.com) Date: 2010-11-23 16:03
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>
> _______________________________________
>
msg122242 - (view) Author: Matthew Barnett (mrabarnett) * (Python triager) Date: 2010-11-23 20:19
textwrap_2010-11-23.diff is my attempt to provide a fix, if it's wanted/needed.
msg122244 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-11-23 20:59
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.
msg122246 - (view) Author: Tom Lynn (tlynn) Date: 2010-11-23 21:34
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.
msg158106 - (view) Author: Otto Kekäläinen (otto) Date: 2012-04-12 06:47
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.
msg158107 - (view) Author: Otto Kekäläinen (otto) Date: 2012-04-12 06:56
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
msg158135 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-04-12 14:30
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)]
msg166625 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-07-28 02:31
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.
msg166627 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-07-28 05:56
> 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']
msg166629 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-07-28 06:51
def wrap_paragraphs(text, width=70, **kwargs):
    return [line for para in text.splitlines() for line in textwrap.wrap(para, width, **kwargs) or ['']]
msg166809 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-07-29 19:58
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.
msg166811 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-07-29 20:23
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.)
msg166816 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-07-29 21:15
If people are interested, I filed a new issue (issue 15492) about textwrap's tab expansion that I noticed while working on this issue.
msg166941 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-07-31 01:29
Marking issue 15510 as a dependency because there is a behavioral issue in existing use cases that affects how to proceed in this issue.
msg167373 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-03 22:48
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.
msg167381 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-08-03 23:37
> 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.
msg167412 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-08-04 15:26
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.
msg214103 - (view) Author: dani (dbudinova) * Date: 2014-03-19 15:15
applied patches textwrap_2010-11-23.diff and issue1859_docs.diff
added line_break tests
History
Date User Action Args
2022-04-11 14:56:29adminsetgithub: 46167
2014-06-24 07:00:10paul.j3setnosy: + paul.j3
2014-03-19 15:15:59dbudinovasetfiles: + line_break_tests.patch
nosy: + dbudinova
messages: + msg214103

2014-02-03 19:09:54BreamoreBoysetnosy: - BreamoreBoy
2012-08-04 19:51:09r.david.murraysetnosy: + r.david.murray
2012-08-04 15:26:36serhiy.storchakasetmessages: + msg167412
2012-08-04 14:00:09jceasetnosy: + jcea
2012-08-03 23:37:34chris.jerdoneksetmessages: + msg167381
2012-08-03 22:48:19pitrousetnosy: + pitrou
messages: + msg167373
2012-07-31 01:29:15chris.jerdoneksetdependencies: + textwrap.wrap('') returns empty list
messages: + msg166941
2012-07-29 21:15:20chris.jerdoneksetmessages: + msg166816
2012-07-29 20:23:56chris.jerdoneksetmessages: + msg166811
2012-07-29 19:58:41chris.jerdoneksetmessages: + msg166809
2012-07-28 06:51:36serhiy.storchakasetmessages: + msg166629
2012-07-28 05:56:38chris.jerdoneksetmessages: + msg166627
2012-07-28 02:31:22chris.jerdoneksetnosy: + chris.jerdonek
messages: + msg166625
2012-04-12 14:30:01serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg158135
2012-04-12 06:56:01ottosetmessages: + msg158107
2012-04-12 06:47:39ottosetnosy: + otto
messages: + msg158106
2010-11-23 21:34:02tlynnsetmessages: + msg122246
2010-11-23 21:00:04terry.reedysetversions: - Python 2.7
2010-11-23 20:59:29terry.reedysetmessages: + msg122244
2010-11-23 20:19:17mrabarnettsetfiles: + textwrap_2010-11-23.diff

messages: + msg122242
2010-11-23 20:10:13terry.reedysetfiles: - unnamed
2010-11-23 16:04:27brian.curtinsetnosy: - Phillip.M.Feldman@gmail.com
2010-11-23 16:03:51Phillip.M.Feldman@gmail.comsetfiles: + unnamed

messages: + msg122222
2010-11-23 07:50:26georg.brandlsetmessages: + msg122200
2010-11-23 06:59:57terry.reedysetmessages: + msg122196
2010-11-23 02:31:32mrabarnettsetnosy: + mrabarnett
messages: + msg122189
2010-11-21 12:37:52georg.brandlsetnosy: + georg.brandl
messages: + msg121914
2010-11-20 15:24:04jerithsetfiles: + issue1859_docs.diff
keywords: + patch
messages: + msg121663
2010-11-20 14:47:05jerithsetnosy: + jerith
messages: + msg121658
2010-09-20 07:42:00BreamoreBoysetnosy: + BreamoreBoy
messages: + msg116915
2009-12-07 18:51:12mark.dickinsonsetassignee: mark.dickinson ->
messages: + msg96064
2009-11-30 06:58:05Phillip.M.Feldman@gmail.comsetnosy: + Phillip.M.Feldman@gmail.com
messages: + msg95831
2009-11-28 22:11:54gwardsetmessages: + msg95800
2009-11-28 18:47:24mark.dickinsonsetmessages: + msg95798
2009-11-28 18:33:47mark.dickinsonsetversions: - Python 2.6, Python 3.1
nosy: + gward

messages: + msg95797

type: behavior -> enhancement
stage: test needed
2009-11-20 20:38:18terry.reedysetnosy: + terry.reedy
messages: + msg95562
2009-11-20 14:17:45mark.dickinsonsetpriority: normal
assignee: mark.dickinson
messages: + msg95547

versions: + Python 2.6, Python 3.1, Python 2.7, Python 3.2, - Python 2.5, Python 2.4
2009-11-19 15:56:23gvanrossumsetstatus: closed -> open
resolution: rejected ->
messages: + msg95483
2009-11-19 13:52:23tlynnsetnosy: + tlynn
messages: + msg95469
2008-01-17 18:40:34gvanrossumsetmessages: + msg60048
2008-01-17 18:39:15mark.dickinsonsetmessages: + msg60047
2008-01-17 18:26:06gvanrossumsetmessages: + msg60045
2008-01-17 18:23:19palfreysetmessages: + msg60043
2008-01-17 18:16:28mark.dickinsonsetmessages: + msg60042
2008-01-17 18:14:05gvanrossumsetmessages: + msg60040
2008-01-17 18:03:31palfreysetmessages: + msg60039
2008-01-17 17:51:40gvanrossumsetstatus: open -> closed
resolution: rejected
messages: + msg60038
nosy: + gvanrossum
2008-01-17 15:51:10palfreysetmessages: + msg60032
2008-01-17 15:24:33mark.dickinsonsetnosy: + mark.dickinson
messages: + msg60031
2008-01-17 12:46:49palfreysetfiles: + textwrap-fix.patch
messages: + msg60027
2008-01-17 12:40:01palfreycreate