Issue15510
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.
Created on 2012-07-31 01:26 by chris.jerdonek, last changed 2022-04-11 14:57 by admin. 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | Date: 2012-08-03 18:37 | |
> I think this is a bug. Do you have any argument? |
|||
msg167352 - (view) | Author: Ethan Furman (ethan.furman) * | 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) * | 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) * | Date: 2012-08-03 21:09 | |
> an empty list is not a list of lines Really? >>> "".splitlines() [] |
|||
msg167358 - (view) | Author: Ethan Furman (ethan.furman) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | Date: 2012-09-01 20:23 | |
Added some review comments on issue-15510-4.patch. |
|||
msg169797 - (view) | Author: Chris Jerdonek (chris.jerdonek) * | 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) * | 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) * | 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) * | 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) | 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) * | Date: 2012-09-08 17:43 | |
Thanks, Chris. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:57:33 | admin | set | github: 59715 |
2012-09-08 17:43:19 | r.david.murray | set | status: open -> closed resolution: fixed messages: + msg170059 stage: patch review -> resolved |
2012-09-08 17:42:41 | python-dev | set | nosy:
+ python-dev messages: + msg170058 |
2012-09-05 04:50:08 | chris.jerdonek | set | files:
+ issue-15510-5.patch messages: + msg169856 |
2012-09-05 03:45:02 | rhettinger | set | nosy:
+ rhettinger messages: + msg169855 |
2012-09-05 01:41:59 | chris.jerdonek | set | messages: + msg169853 |
2012-09-03 19:11:16 | chris.jerdonek | set | messages: + msg169797 |
2012-09-01 20:23:55 | r.david.murray | set | messages: + msg169669 |
2012-08-29 11:53:27 | chris.jerdonek | set | files:
+ issue-15510-4.patch messages: + msg169368 |
2012-08-26 04:25:54 | chris.jerdonek | set | keywords:
+ needs review files: + issue-15510-3.patch type: behavior -> enhancement messages: + msg169160 |
2012-08-08 20:34:54 | r.david.murray | set | messages: + msg167712 |
2012-08-08 20:17:45 | ethan.furman | set | messages: + msg167709 |
2012-08-08 02:22:48 | chris.jerdonek | set | messages: + msg167652 |
2012-08-08 01:54:07 | gward | set | messages: + msg167651 |
2012-08-04 19:50:12 | r.david.murray | set | nosy:
+ r.david.murray messages: + msg167435 |
2012-08-04 02:16:49 | chris.jerdonek | set | messages: + msg167392 |
2012-08-04 00:33:40 | pitrou | set | messages: + msg167388 |
2012-08-04 00:32:03 | chris.jerdonek | set | messages: + msg167387 |
2012-08-04 00:12:46 | pitrou | set | messages: + msg167385 |
2012-08-04 00:05:23 | chris.jerdonek | set | messages: + msg167384 |
2012-08-03 22:45:55 | pitrou | set | messages: + msg167372 |
2012-08-03 22:41:37 | chris.jerdonek | set | messages: + msg167371 |
2012-08-03 21:42:47 | pitrou | set | messages: + msg167366 |
2012-08-03 21:39:34 | ethan.furman | set | messages: + msg167365 |
2012-08-03 21:28:29 | pitrou | set | messages: + msg167362 |
2012-08-03 21:24:41 | ethan.furman | set | messages: + msg167359 |
2012-08-03 21:17:57 | ethan.furman | set | messages: + msg167358 |
2012-08-03 21:09:17 | pitrou | set | messages: + msg167355 |
2012-08-03 21:01:41 | ethan.furman | set | messages: + msg167353 |
2012-08-03 21:00:10 | ethan.furman | set | nosy:
+ ethan.furman messages: + msg167352 |
2012-08-03 18:37:32 | pitrou | set | messages: + msg167341 |
2012-08-03 17:32:46 | jcea | set | stage: patch review |
2012-08-03 17:02:33 | jcea | set | messages:
+ msg167339 stage: patch review -> (no value) |
2012-08-01 20:56:34 | chris.jerdonek | set | messages: + msg167167 |
2012-08-01 14:04:26 | pitrou | set | nosy:
+ pitrou messages: + msg167130 |
2012-08-01 09:16:01 | chris.jerdonek | set | messages: + msg167102 |
2012-07-31 22:00:53 | chris.jerdonek | set | files:
+ issue-15510-2.patch messages: + msg167055 |
2012-07-31 20:29:36 | chris.jerdonek | set | files:
+ issue-15510-1.patch keywords: + patch messages: + msg167047 stage: patch review |
2012-07-31 17:09:57 | chris.jerdonek | set | messages: + msg167020 |
2012-07-31 16:48:56 | jcea | set | nosy:
+ twouters, gward, jcea messages: + msg167017 versions: + Python 2.7, Python 3.2, Python 3.3 |
2012-07-31 01:29:15 | chris.jerdonek | link | issue1859 dependencies |
2012-07-31 01:26:18 | chris.jerdonek | create |