classification
Title: textwrap.wrap('') returns empty list
Type: enhancement Stage: resolved
Components: Versions: Python 3.2, Python 3.3, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: chris.jerdonek, ethan.furman, gward, jcea, pitrou, python-dev, r.david.murray, rhettinger, twouters
Priority: normal Keywords: needs review, patch

Created on 2012-07-31 01:26 by chris.jerdonek, last changed 2012-09-08 17:43 by r.david.murray. This issue is now closed.

Files
File name Uploaded Description Edit
issue-15510-1.patch chris.jerdonek, 2012-07-31 20:29 review
issue-15510-2.patch chris.jerdonek, 2012-07-31 22:00 review
issue-15510-3.patch chris.jerdonek, 2012-08-26 04:25 Patch keeping existing behavior. review
issue-15510-4.patch chris.jerdonek, 2012-08-29 11:53 review
issue-15510-5.patch chris.jerdonek, 2012-09-05 04:50 review
Messages (39)
msg166940 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-07-31 01:26
While working on issue 1859, I found that textwrap.wrap() returns an empty list when passed the empty string:

>>> from textwrap import wrap
>>> wrap('')
[]

as opposed to a list containing the empty string which is what I expected--

['']

I originally accepted this as intended behavior, but for the following reasons I now think it is a bug that we should consider fixing:

1. The textwrap documentation says that wrap(), "Wraps the single paragraph in text (a string) so every line is at most width characters long. Returns a list of output lines, without final newlines."  The empty string is less than width characters long, so following the documentation, wrapping should not change it.

2. It is known that wrap() is broken for strings containing newlines (i.e. strings containing more than one paragraph).  Indeed, this is the issue that issue 1859 is meant to fix.

The commonly recommended work-around is to call splitlines() on the incoming string, pass the pieces to wrap(), and then join the return values on newlines.

However, the behavior described in this issue causes this workaround not to behave sensibly when the original string contains breaks between paragraphs.  See this message, for example:

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

Currently, this work-around would return "a\nb" for both "a\nb" and "a\n\nb" for example when common sense says it should preserve the newlines and return "a\nb" and "a\n\nb", respectively.

3. In addition, the behavior causes the following inconsistent behavior:

>>> repr(wrap('  ', drop_whitespace=False))
"['  ']"
>>> repr(wrap('  ', drop_whitespace=True))
'[]'

The documentation says this about drop_whitespace: "If true, whitespace that, after wrapping, happens to end up at the beginning or end of a line is dropped."  If the first case is correct, then, the second case should at least return a non-empty list because that is what would result from dropping whitespace from the string '  ' in the first list.  This is how drop_whitespace behaves when the string contains non-whitespace characters:

>>> repr(wrap('a  ', drop_whitespace=False))
"['a  ']"
>>> repr(wrap('a  ', drop_whitespace=True))
"['a']"

4. There is no unit test for the case of the empty string, and existing tests still pass after fixing the issue.

If we cannot correct this behavior, then I feel we should at least document the inconsistent behavior, and then work around it in the fix for issue 1859.

Marking for this issue to be resolved either way before fixing issue 1859.  I am happy to prepare the patch.
msg167017 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2012-07-31 16:48
I think this is a bug.

Could you possibly write a patch for 2.7, 3.2 and 3.3?. With a test :-)

I am worried about changing a behaviour that somebody is depending of. Opinions?

Adding a couple of persons I think that could have an opinion about this.
msg167020 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-07-31 17:09
> Could you possibly write a patch for 2.7, 3.2 and 3.3?. With a test :-)

I would be happy to write a patch with tests (I think there may be a few edge cases we would want to test here).  Should be ready within the next one or two days.
msg167047 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-07-31 20:29
Attaching patch with test cases.

I added 6 new tests:

*test_empty_string
test_whitespace_trailing
*test_drop_whitespace__all_whitespace
*test_initial_indent__empty_string
test_subsequent_indent__trailing_whitespace
test_subsequent_indent__long_indent

The starred ones fail with the current code (the test cases are similar to the snippets I included in my first comment).  The others fail under a certain incorrect implementation of this issue.  (I'm adding them to increase coverage of edge cases and to protect against future regressions.)
msg167055 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-07-31 22:00
Actually, here is a slightly more benign version of the patch.

This patch makes the change in the wrap() method and leaves _wrap_chunks() alone.

This is less intrusive because it doesn't change the behavior of _wrap_chunks(), which some people might be calling if they are subclassing TextWrapper and accessing the private API directly.
msg167102 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-08-01 09:16
I verified that this patch can be applied to 2.7 and that those tests pass as well.
msg167130 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-01 14:04
Uh, how is this a bug? An empty text doesn't contain lines at all, so returning an empty list of lines sounds right.

Furthermore, by "fixing" this, you may break existing software.
msg167167 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-08-01 20:56
Here are additional test cases impacted by this issue:

>>> wrap("   ")
[]
>>> wrap("\n\n\n")
[]
>>> wrap("\n\n\n", replace_whitespace=False)
[]
>>> wrap("  \n\n", replace_whitespace=False)
[]
msg167339 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2012-08-03 17:02
I think this is a bug. The question to ponder is backwards compatibility, specially if this is going to be backported to 2.7/3.2.

Chris, could you possibly ask for opinions in python-dev and/or python-list?
msg167341 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-03 18:37
> I think this is a bug.

Do you have any argument?
msg167352 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2012-08-03 21:00
The documentation says, "Returns a list of output lines"; an empty list is not a list of lines.
msg167353 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2012-08-03 21:01
Not sure I would worry about fixing it in 2.7, although I don't have strong feelings about that.
msg167355 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-03 21:09
> an empty list is not a list of lines

Really?

>>> "".splitlines()
[]
msg167358 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2012-08-03 21:17
Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
> 
>> an empty list is not a list of lines
> 
> Really?
> 
>>>> "".splitlines()
> []

Really.

--> ''.split('\n')
['']
msg167359 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2012-08-03 21:24
Ethan Furman wrote:
>> Antoine Pitrou added the comment:
>>
>>>>> "".splitlines()
>> []
> 
> --> ''.split('\n')
> ['']

I see the docs have been fixed in 3 to explain the not present last 
empty line.

However, sure this is still not correct?

--> wrap('   ')
[]

So if you have code that loops over the return and prints it out:

for line in wrap(blah):
     print(line)

you will have different output with [] than with [''].
msg167362 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-03 21:28
> Really.
> 
> --> ''.split('\n')
> ['']

You claimed that an empty list is not a list of lines. I countered that
splitlines(), which *by definition* returns a list of lines, can return
an empty list, therefore textwrap.wrap() is not exotic in its behaviour.
Whether or not split() behaves differently is irrelevant.

> So if you have code that loops over the return and prints it out:
> 
> for line in wrap(blah):
>      print(line)
> 
> you will have different output with [] than with [''].

Indeed, which is a good reason *not* to change textwrap.wrap's
behaviour. The current behaviour is as reasonable as any other, and
changing it would break compatibility.
msg167365 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2012-08-03 21:39
Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
> 
>> Really.
>>
>> --> ''.split('\n')
>> ['']
> 
> You claimed that an empty list is not a list of lines. I countered that
> splitlines(), which *by definition* returns a list of lines, can return
> an empty list, therefore textwrap.wrap() is not exotic in its behaviour.
> Whether or not split() behaves differently is irrelevant.

Not at all -- it's a warning to think "Why does this shortcut function 
exist?  How is it different?"  Something I will pay more attention to.  ;)

>> So if you have code that loops over the return and prints it out:
>>
>> for line in wrap(blah):
>>      print(line)
>>
>> you will have different output with [] than with [''].
> 
> Indeed, which is a good reason *not* to change textwrap.wrap's
> behaviour. The current behaviour is as reasonable as any other, and
> changing it would break compatibility.

For an empty string, sure -- for a string with nothing but white space, no:

--> wrap('   ')
[]
--> '    '.splitlines()
['    ']
msg167366 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-03 21:42
> For an empty string, sure -- for a string with nothing but white space, 
> no:

> --> wrap('   ')
> []

That's because wrap() suppresses extra whitespace by default. Once extra whitespace is suppressed, you are left with an empty text, meaning an empty list of lines. That's perfectly logical.
msg167371 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-08-03 22:41
> That's because wrap() suppresses extra whitespace by default. 

But the documentation for drop_whitespace clearly states that, after wrapping, "leading whitespace in the first line is always preserved, though."

> Once extra whitespace is suppressed, you are left with an empty text, meaning an empty list of lines. That's perfectly logical.

I wouldn't say that it is "perfectly" logical.  String methods that drop characters from the beginning or end of a string return an empty string for empty text.

>>> "   ".strip()
''

> Furthermore, by "fixing" this, you may break existing software.

Issue 1859 is an arguably larger change that will also break existing software, and that issue has been kept open.

One scenario to consider: if we agree to fix issue 1859 in some versions, might that change whether we should address this issue in those versions as well?
msg167372 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-03 22:45
> > That's because wrap() suppresses extra whitespace by default. 
> 
> But the documentation for drop_whitespace clearly states that, after
> wrapping, "leading whitespace in the first line is always preserved,
> though."

Ok, then it's a bit fuzzy. That whitespace is as much trailing as
leading, after all :)

> I wouldn't say that it is "perfectly" logical.  String methods that
> drop characters from the beginning or end of a string return an empty
> string for empty text.
> 
> >>> "   ".strip()
> ''

I'm not sure I see the relevance. strip() returns an empty string
because its return type is a string, what else could it return?

> > Furthermore, by "fixing" this, you may break existing software.
> 
> Issue 1859 is an arguably larger change that will also break existing
> software, and that issue has been kept open.

Agreed. I'm gonna post on that issue too.
msg167384 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-08-04 00:05
> > wrapping, "leading whitespace in the first line is always preserved,
> > though."
> Ok, then it's a bit fuzzy. That whitespace is as much trailing as
> leading, after all :)

That's why the word "always" is there. :)

> I'm not sure I see the relevance. strip() returns an empty string
> because its return type is a string, what else could it return?

My point was that your line of logic was not as clear-cut as you suggested.  One could argue that dropping whitespace to become the empty string is more reasonable than dropping it become "no string".

Is it your opinion that no changes to textwrap should be made in any versions that change existing behavior on some input?  Otherwise, what are your criteria?
msg167385 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-04 00:12
Le samedi 04 août 2012 à 00:05 +0000, Chris Jerdonek a écrit :
> Chris Jerdonek added the comment:
> 
> > > wrapping, "leading whitespace in the first line is always preserved,
> > > though."
> > Ok, then it's a bit fuzzy. That whitespace is as much trailing as
> > leading, after all :)
> 
> That's why the word "always" is there. :)

I'm not sure that's the right interpretation. The only point of
preserving whitespace is to preserve indentation, which is pointless
when there's nothing after the whitespace.

> > I'm not sure I see the relevance. strip() returns an empty string
> > because its return type is a string, what else could it return?
> 
> My point was that your line of logic was not as clear-cut as you
> suggested.  One could argue that dropping whitespace to become the
> empty string is more reasonable than dropping it become "no string".

Of course. The point is, if the alternative is no better than the
current behaviour, the status quo wins.

> Is it your opinion that no changes to textwrap should be made in any
> versions that change existing behavior on some input?

As far as these changes don't fix obvious bugs, no, they shouldn't.
People certainly rely on the current behaviour, and they will start
getting extraneous newlines if you change it (because they will call
'\n'.join(...)).
msg167387 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-08-04 00:32
> As far as these changes don't fix obvious bugs, no, they shouldn't.
People certainly rely on the current behaviour, and they will start
getting extraneous newlines if you change it (because they will call
'\n'.join(...)).

That line of reasoning is acceptable to me.  And I said from the beginning that I'm open to resolving this issue via changes to the documentation.

But I feel this criterion was not applied to issue 1859.  wrap()'s behavior on newlines is broken to the point that multi-paragraph input is acknowledged as not working.  Additionally, because of that the keyword argument replace_whitespace has no clear use case.  That seems like an obvious bug to me.
msg167388 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-04 00:33
Le samedi 04 août 2012 à 00:32 +0000, Chris Jerdonek a écrit :
> But I feel this criterion was not applied to issue 1859.  wrap()'s
> behavior on newlines is broken to the point that multi-paragraph input
> is acknowledged as not working.  Additionally, because of that the
> keyword argument replace_whitespace has no clear use case.  That seems
> like an obvious bug to me.

Ok, I probably read the issue too quickly. Feel free to ignore my
comment then :-)
msg167392 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-08-04 02:16
> Ok, I probably read the issue too quickly. Feel free to ignore my
> comment then :-)

Thanks.  I will prepare another patch for this issue with documentation and test cases of existing behavior.  The discussion can of course continue if anyone would like to weigh in further.
msg167435 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-08-04 19:50
FTR I agree with Antoine that returning the empty list is the more logical behavior here.  Wrap is turning a string into a list of lines...if there is no content, the list of lines *should* be empty, IMO.  That is what I would expect, so for me the empty list follows the principle of least surprise here.  Consider, for example, the fact that [] is False, while [''] is True.  I consider that definitive in favor of returning an empty list when there is no content to wrap, even ignoring the backward compatibility issue.

The issue of preserving whitespace-only is fuzzier, but given that it is fuzzy I also am inclined to leave the current behavior alone (and document it properly).  As Antoine said, there is no point in preserving whitespace unless it is preserving indentation, and if there is nothing but whitespace there is nothing to be indented.
msg167651 - (view) Author: Greg Ward (gward) (Python committer) Date: 2012-08-08 01:54
Random comments from original author of textwrap.py, in case anyone cares at this point...

* This is a pretty obscure edge case, and I admit that it never occurred to me when writing the code. (If it had, I would have tested it!)

* One can debate endlessly about whether this is a bug or not -- witness the recent discussion on this bug. Meh. Not interesting. IMHO it's better described as undefined behaviour. If you want it defined, write tests to enforce the status quo and improve the docs.

* If there is a consensus to change the current behaviour, IMHO it should NOT be done on 2.7. Even if the new behaviour is better by some definition, it's still a behaviour change that could bite someone. Those changes should happen when you make a major upgrade (3.2 to 3.3, say), not when you make a bug fix upgrade (2.7.3 to 2.7.4). IOW: keep it on trunk. Or default, whatever we're calling it these days. ;-)
msg167652 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-08-08 02:22
Thanks for weighing in, Greg!

At least for me, this edge case was important because it determines how the canonical advice or recipe for handling multiple paragraphs behaves when the input string has line breaks in between paragraphs.  That advice, of course, is to call splitlines(), pass the individual paragraphs to wrap(), and then join on newlines.

Here is an example on a paragraph with line breaks between paragraphs:

>>> def wrap_paras(text, width=70, **kwargs):
...     lines = [line for para in text.splitlines()
...                   for line in wrap(para, width, **kwargs)]
...     return "\n".join(lines)
...
>>> text = """\
... abcd abcd
...
... abcd abcd"""
>>> print(wrap_paras(text))
abcd abcd
abcd abcd

The edge case we're discussing determines whether line breaks between paragraphs are preserved in the result.  (With current behavior, they are not.)

> If you want it defined, write tests to enforce the status quo and improve the docs.

Given the discussion so far (and in particular, opposition to changing behavior), this is the route I'm hoping we can go.  Interesting or not, I think it's good that we at least had this discussion before setting the behavior in stone. :)
msg167709 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2012-08-08 20:17
Chris Jerdonek wrote:
> Here is an example on a paragraph with line breaks between paragraphs:

s/paragraph/text/

>>>> def wrap_paras(text, width=70, **kwargs):
> ...     lines = [line for para in text.splitlines()
> ...                   for line in wrap(para, width, **kwargs)]
> ...     return "\n".join(lines)
> ...
>>>> text = """\
> ... abcd abcd
> ...
> ... abcd abcd"""
>>>> print(wrap_paras(text))
> abcd abcd
> abcd abcd
> 
> The edge case we're discussing determines whether line breaks between paragraphs are preserved in the result.  (With current behavior, they are not.)

Having now more carefully read the docs (which, admittedly, I should 
have done before responding the first time) I found this:

textwrap.wrap(text, width=70, **kwargs)
	Wraps the single paragraph in text . . .

textwrap.fill(text, width=70, **kwargs)
	Wraps the single paragraph in text, . . .

In other words, it is not designed to work on multiple paragraphs at 
once.  And the documentation is fine.

Move along, no bug to see here, move along...
msg167712 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-08-08 20:34
Also you will note that the return of the empty list for an empty line is exactly what you want for wrapping multiple line-break-delimited paragraphs.  Consider:

  >>> doc = "a para\nanother para\n\na third, but with an extra blank line between\n"
  >>> for line in doc.splitlines():
  ...    print('\n'.join(textwrap.wrap(line, width=5)))
  ...    if line:
  ...       print()
  a
  para

  anoth
  er
  para


  a thi
  rd,
  but
  with
  an
  extra
  blank
  line 
  betwe
  en

In other words, we need to add a blank line after our formatted paragraph, unless it is empty, in which case we don't want to add one or we'll have an extra.  This assumes that single-line-paragraphs do not have blank lines between them...if they do, then the algorithm is even simpler, as you don't need the if.
msg169160 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-08-26 04:25
Here is a patch that documents and adds tests for the existing behavior (i.e. keeping the current behavior the same).

I also expanded the patch slightly to cover related edge cases that involve the interplay between whitespace, empty lines, and indenting (some of which came out of the discussions above).
msg169368 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-08-29 11:53
Attaching an updated patch that improves the organization of the new test cases (test ordering, test names, and test comments, etc).
msg169669 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-09-01 20:23
Added some review comments on issue-15510-4.patch.
msg169797 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-09-03 19:11
Thanks a lot for the very thorough review, David.  I should be able to update the patch and respond to a couple of your points later today or tomorrow at the latest.
msg169853 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-09-05 01:41
I responded to David's comments on the review tool.  Later today I will update the patch in response to his comments (accommodating all of his suggestions) along with a couple other changes.
msg169855 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2012-09-05 03:45
FWIW, I agree that the existing behavior should not be changed.  Most likely, a change would break some code that is currently working, and there would be little to no gain.
msg169856 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-09-05 04:50
Attaching an updated patch as promised in my previous comment.

Note that I removed two edge test cases pertaining to leading whitespace.  I would rather discuss those cases as part of a different issue to avoid making this thread even longer (and it is off the topic of the original issue).
msg170058 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-09-08 17:42
New changeset 65e5f28801e1 by R David Murray in branch '3.2':
#15510: clarify textwrap's handling of whitespace, and add confirming tests.
http://hg.python.org/cpython/rev/65e5f28801e1

New changeset 0e9ad455355b by R David Murray in branch 'default':
Merge #15510: clarify textwrap's handling of whitespace, and add confirming tests.
http://hg.python.org/cpython/rev/0e9ad455355b

New changeset fca48971ac35 by R David Murray in branch '2.7':
#15510: clarify textwrap's handling of whitespace, and add confirming tests.
http://hg.python.org/cpython/rev/fca48971ac35
msg170059 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-09-08 17:43
Thanks, Chris.
History
Date User Action Args
2012-09-08 17:43:19r.david.murraysetstatus: open -> closed
resolution: fixed
messages: + msg170059

stage: patch review -> resolved
2012-09-08 17:42:41python-devsetnosy: + python-dev
messages: + msg170058
2012-09-05 04:50:08chris.jerdoneksetfiles: + issue-15510-5.patch

messages: + msg169856
2012-09-05 03:45:02rhettingersetnosy: + rhettinger
messages: + msg169855
2012-09-05 01:41:59chris.jerdoneksetmessages: + msg169853
2012-09-03 19:11:16chris.jerdoneksetmessages: + msg169797
2012-09-01 20:23:55r.david.murraysetmessages: + msg169669
2012-08-29 11:53:27chris.jerdoneksetfiles: + issue-15510-4.patch

messages: + msg169368
2012-08-26 04:25:54chris.jerdoneksetkeywords: + needs review
files: + issue-15510-3.patch
type: behavior -> enhancement
messages: + msg169160
2012-08-08 20:34:54r.david.murraysetmessages: + msg167712
2012-08-08 20:17:45ethan.furmansetmessages: + msg167709
2012-08-08 02:22:48chris.jerdoneksetmessages: + msg167652
2012-08-08 01:54:07gwardsetmessages: + msg167651
2012-08-04 19:50:12r.david.murraysetnosy: + r.david.murray
messages: + msg167435
2012-08-04 02:16:49chris.jerdoneksetmessages: + msg167392
2012-08-04 00:33:40pitrousetmessages: + msg167388
2012-08-04 00:32:03chris.jerdoneksetmessages: + msg167387
2012-08-04 00:12:46pitrousetmessages: + msg167385
2012-08-04 00:05:23chris.jerdoneksetmessages: + msg167384
2012-08-03 22:45:55pitrousetmessages: + msg167372
2012-08-03 22:41:37chris.jerdoneksetmessages: + msg167371
2012-08-03 21:42:47pitrousetmessages: + msg167366
2012-08-03 21:39:34ethan.furmansetmessages: + msg167365
2012-08-03 21:28:29pitrousetmessages: + msg167362
2012-08-03 21:24:41ethan.furmansetmessages: + msg167359
2012-08-03 21:17:57ethan.furmansetmessages: + msg167358
2012-08-03 21:09:17pitrousetmessages: + msg167355
2012-08-03 21:01:41ethan.furmansetmessages: + msg167353
2012-08-03 21:00:10ethan.furmansetnosy: + ethan.furman
messages: + msg167352
2012-08-03 18:37:32pitrousetmessages: + msg167341
2012-08-03 17:32:46jceasetstage: patch review
2012-08-03 17:02:33jceasetmessages: + msg167339
stage: patch review -> (no value)
2012-08-01 20:56:34chris.jerdoneksetmessages: + msg167167
2012-08-01 14:04:26pitrousetnosy: + pitrou
messages: + msg167130
2012-08-01 09:16:01chris.jerdoneksetmessages: + msg167102
2012-07-31 22:00:53chris.jerdoneksetfiles: + issue-15510-2.patch

messages: + msg167055
2012-07-31 20:29:36chris.jerdoneksetfiles: + issue-15510-1.patch
keywords: + patch
messages: + msg167047

stage: patch review
2012-07-31 17:09:57chris.jerdoneksetmessages: + msg167020
2012-07-31 16:48:56jceasetnosy: + twouters, gward, jcea

messages: + msg167017
versions: + Python 2.7, Python 3.2, Python 3.3
2012-07-31 01:29:15chris.jerdoneklinkissue1859 dependencies
2012-07-31 01:26:18chris.jerdonekcreate