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)?