Issue 1859: textwrap doesn't linebreak on "\n" (original) (raw)
Created on 2008-01-17 12:40 by palfrey, last changed 2022-04-11 14:56 by admin.
Messages (46)
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.
Author: Tom Parker (palfrey)
Date: 2008-01-17 12:46
Attaching a patch that corrects the issue (against python 2.4)
Author: Mark Dickinson (mark.dickinson) * 
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.
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".
Author: Guido van Rossum (gvanrossum) *
Date: 2008-01-17 17:51
The original behavior is intentional. Please don't attempt to "fix" it.
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?
Author: Guido van Rossum (gvanrossum) *
Date: 2008-01-17 18:14
Use .splitlines() to break the input into lines, wrap each "line" separately, and join again?
Author: Mark Dickinson (mark.dickinson) *
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.
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.
Author: Guido van Rossum (gvanrossum) *
Date: 2008-01-17 18:26
Mark, it looks like the replace_whitespace flag shouldn't be used with input containing newlines.
Author: Mark Dickinson (mark.dickinson) *
Date: 2008-01-17 18:39
Is it worth double checking with Greg Ward that this behaviour really is intentional?
Author: Guido van Rossum (gvanrossum) *
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)?
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.
Author: Guido van Rossum (gvanrossum) *
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.
Author: Mark Dickinson (mark.dickinson) *
Date: 2009-11-20 14:17
I'll take a look.
Author: Terry J. Reedy (terry.reedy) *
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.
Author: Mark Dickinson (mark.dickinson) *
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?
Author: Mark Dickinson (mark.dickinson) *
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.
Author: Greg Ward (gward)
Date: 2009-11-28 22:11
Greg, any comment on this issue?
Yes, two:
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.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:
- I agree with tlynn that the example in 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.
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
Author: Mark Dickinson (mark.dickinson) *
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?
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 :(
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.
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.
Author: Georg Brandl (georg.brandl) *
Date: 2010-11-21 12:37
+1 for applying the doc patch.
Author: Matthew Barnett (mrabarnett) * 
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)?
Author: Terry J. Reedy (terry.reedy) *
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?
Author: Georg Brandl (georg.brandl) *
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.
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>
Author: Matthew Barnett (mrabarnett) *
Date: 2010-11-23 20:19
textwrap_2010-11-23.diff is my attempt to provide a fix, if it's wanted/needed.
Author: Terry J. Reedy (terry.reedy) *
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.
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.
Author: Otto Kekäläinen (otto)
Date: 2012-04-12 06:47
As a note to comments -, 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.
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
Author: Serhiy Storchaka (serhiy.storchaka) *
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)]
Author: Chris Jerdonek (chris.jerdonek) *
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.
Author: Chris Jerdonek (chris.jerdonek) *
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']
Author: Serhiy Storchaka (serhiy.storchaka) *
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 ['']]
Author: Chris Jerdonek (chris.jerdonek) *
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.
Author: Chris Jerdonek (chris.jerdonek) *
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.)
Author: Chris Jerdonek (chris.jerdonek) *
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.
Author: Chris Jerdonek (chris.jerdonek) *
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.
Author: Antoine Pitrou (pitrou) *
Date: 2012-08-03 22:48
After discussing , I think this should probably be left as-is, or be implemented in a separate function so as to avoid breaking compatibility.
Author: Chris Jerdonek (chris.jerdonek) *
Date: 2012-08-03 23:37
After discussing , 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.
Author: Serhiy Storchaka (serhiy.storchaka) *
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('
%s
' % ''.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.
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:29
admin
set
github: 46167
2014-06-24 07:00:10
paul.j3
set
nosy: + paul.j3
2014-03-19 15:15:59
dbudinova
set
files: + line_break_tests.patch
nosy: + dbudinova
messages: +
2014-02-03 19:09:54
BreamoreBoy
set
nosy: - BreamoreBoy
2012-08-04 19:51:09
r.david.murray
set
nosy: + r.david.murray
2012-08-04 15:26:36
serhiy.storchaka
set
messages: +
2012-08-04 14:00:09
jcea
set
nosy: + jcea
2012-08-03 23:37:34
chris.jerdonek
set
messages: +
2012-08-03 22:48:19
pitrou
set
nosy: + pitrou
messages: +
2012-07-31 01:29:15
chris.jerdonek
set
dependencies: + textwrap.wrap('') returns empty list
messages: +
2012-07-29 21:15:20
chris.jerdonek
set
messages: +
2012-07-29 20:23:56
chris.jerdonek
set
messages: +
2012-07-29 19:58:41
chris.jerdonek
set
messages: +
2012-07-28 06:51:36
serhiy.storchaka
set
messages: +
2012-07-28 05:56:38
chris.jerdonek
set
messages: +
2012-07-28 02:31:22
chris.jerdonek
set
nosy: + chris.jerdonek
messages: +
2012-04-12 14:30:01
serhiy.storchaka
set
nosy: + serhiy.storchaka
messages: +
2012-04-12 06:56:01
otto
set
messages: +
2012-04-12 06:47:39
otto
set
nosy: + otto
messages: +
2010-11-23 21:34:02
tlynn
set
messages: +
2010-11-23 21:00:04
terry.reedy
set
versions: - Python 2.7
2010-11-23 20:59:29
terry.reedy
set
messages: +
2010-11-23 20:19:17
mrabarnett
set
files: + textwrap_2010-11-23.diff
messages: +
2010-11-23 20:10:13
terry.reedy
set
files: - unnamed
2010-11-23 16:04:27
brian.curtin
set
nosy: - Phillip.M.Feldman@gmail.com
2010-11-23 16:03:51
set
files: + unnamed
messages: +
2010-11-23 07:50:26
georg.brandl
set
messages: +
2010-11-23 06:59:57
terry.reedy
set
messages: +
2010-11-23 02:31:32
mrabarnett
set
nosy: + mrabarnett
messages: +
2010-11-21 12:37:52
georg.brandl
set
nosy: + georg.brandl
messages: +
2010-11-20 15:24:04
jerith
set
files: + issue1859_docs.diff
keywords: + patch
messages: +
2010-11-20 14:47:05
jerith
set
nosy: + jerith
messages: +
2010-09-20 07:42:00
BreamoreBoy
set
nosy: + BreamoreBoy
messages: +
2009-12-07 18:51:12
mark.dickinson
set
assignee: mark.dickinson ->
messages: +
2009-11-30 06:58:05
set
nosy: + Phillip.M.Feldman@gmail.com
messages: +
2009-11-28 22:11:54
gward
set
messages: +
2009-11-28 18:47:24
mark.dickinson
set
messages: +
2009-11-28 18:33:47
mark.dickinson
set
versions: - Python 2.6, Python 3.1
nosy: + gward
messages: +
type: behavior -> enhancement
stage: test needed
2009-11-20 20:38:18
terry.reedy
set
nosy: + terry.reedy
messages: +
2009-11-20 14:17:45
mark.dickinson
set
priority: normal
assignee: mark.dickinson
messages: +
versions: + Python 2.6, Python 3.1, Python 2.7, Python 3.2, - Python 2.5, Python 2.4
2009-11-19 15:56:23
gvanrossum
set
status: closed -> open
resolution: rejected ->
messages: +
2009-11-19 13:52:23
tlynn
set
nosy: + tlynn
messages: +
2008-01-17 18:40:34
gvanrossum
set
messages: +
2008-01-17 18:39:15
mark.dickinson
set
messages: +
2008-01-17 18:26:06
gvanrossum
set
messages: +
2008-01-17 18:23:19
palfrey
set
messages: +
2008-01-17 18:16:28
mark.dickinson
set
messages: +
2008-01-17 18:14:05
gvanrossum
set
messages: +
2008-01-17 18:03:31
palfrey
set
messages: +
2008-01-17 17:51:40
gvanrossum
set
status: open -> closed
resolution: rejected
messages: +
nosy: + gvanrossum
2008-01-17 15:51:10
palfrey
set
messages: +
2008-01-17 15:24:33
mark.dickinson
set
nosy: + mark.dickinson
messages: +
2008-01-17 12:46:49
palfrey
set
files: + textwrap-fix.patch
messages: +
2008-01-17 12:40:01
palfrey
create