Title: unittest.TestCase.assertCountEqual is a very misleading name
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.9
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: aldencolerain, ezio.melotti, georg.brandl, graingert, gregory.p.smith, martin.panter, michael.foord, r.david.murray, rbcollins, rhettinger, serhiy.storchaka, terry.reedy, vitaly
Priority: normal Keywords:

Created on 2016-05-20 23:53 by vitaly, last changed 2020-09-11 22:05 by terry.reedy. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 16228 closed graingert, 2019-09-17 11:05
Messages (39)
msg265980 - (view) Author: Vitaly (vitaly) Date: 2016-05-20 23:53
Somewhere in 3.x assertItemsEqual was renamed to assertCountEqual.

assertCountEqual sounds like a really inappropriate, misleading name for what it does. It misleads users into thinking that it only compares the number of elements in each sequence, whereas it actually asserts that equivalent items are present in both sequences, regardless of order. The original name from 2.7 assertItemsEqual was so much more meaningful.
msg265984 - (view) Author: Vitaly (vitaly) Date: 2016-05-21 00:08
The new name by itself does not sufficiently reflect the subtlety of element-by-element counts, which does a disservice to the readability of test code. And it's also an unnecessary incompatibility between 2.7 and 3.x.
msg266115 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2016-05-22 23:03
I don't particularly like either name FWIW :) - but sure, we can add a different name and deprecate assertCountEqual - but before we do anything lets look up the previous issue where the rename was done.
msg266121 - (view) Author: Vitaly (vitaly) Date: 2016-05-23 05:31
As far as I can tell, issue #10242 deals with the renaming. I think that the arguments for the new name are flawed (sorry to be so blunt, but I don't know how else to express it).

Regardless of whether it's Count or Counts, to most people it sounds like it's going to compare just the simple counts of the elements (i.e., lengths of the sequences). Ask yourself the questions: 1. What is the element count in sequence S? Reasonable answer: len(S).  2. What are the element counts of sequences Q and S? Reasonable answer len(Q) and len(S). Those are the most straightforward, non-nuanced answers you would get from most people IMHO.

With ambiguous names like these, readability of the code is greatly diminished. When I review code, a name like assertCountEqual tells me (and likely most other reviewers) that it's comparing lengths of the sequences, and I have no reason to resort to the documentation. A well-named function should do what its name says, and its name should say what it does. assertCountEqual doesn't pass that test, unless you read the documentation, and apply the nuanced interpretation that is biased by the documentation. assertElementCountsEqual is in the same category, I am afraid :) The straightforward interpretation of these names is misleading at worst and ambiguous at best.

I think that the authors of the new name assertCountEqual were thinking along the lines of "assert frequency counts equal", which might lead to the arguably unambiguous name assertFrequencyCountsEqual, but but all that sounds more complicated than it needs to be.

Personally, something like assertElementsEqual seems to me to capture the spirit of the assertion better and is easier for most people to grasp. It doesn't imply order as it emphasizes the elements (vs. assertSequenceEqual, which emphasizes sequence), and it doesn't imply uniqueness. I like assertElementsEqual more than assertItemsEqual, but then again, assertElementsEqual is not sufficiently better than assertItemsEqual to warrant a backward-incompatible name change in my opinion.
msg266123 - (view) Author: Vitaly (vitaly) Date: 2016-05-23 06:01
If there really is a good systemic reason why names like assertItemsEqual and assertElementsEqual are flawed, then assertFrequencyCountsEqual might be a less-ambiguous alternative.
msg266153 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-23 14:49
Personally I don't see any difference between assertCountsEqual and assertFrequencyCountsEqual.  The logic for assertCountsEqual is that it is asserting that some counts are equal in this sequence.  What could we be counting?  The only obvious thing is the length of the collections of equal elements.  'Count' was chosen because it references itertools.count, which it can be defined in terms of, as indicated in the docs.  The presence of absence of the s doesn't affect that rationale for the name.

The flaw in assertItems(Elements)Equal is that it implies that each pair of element is equal, implying that the *orders* are the same, which is exactly the opposite of the intent.

This is the kind of bikeshed that can go on for weeks on a mailing list.  I say leave well enough alone unless someone comes up with a simply brilliant better name.
msg266160 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2016-05-23 16:03
I agree with David, I don't like the name but it is at least accurate (if you already understand what it does). assertItemsEqual was better but misleading. In the absence of a *dramatically* better name leave it alone.
msg266164 - (view) Author: Vitaly (vitaly) Date: 2016-05-23 16:39
Gentlemen, the point is that the name of a function should be all that is necessary to unambiguously understand what this method does without having to know that it's implemented in terms of collections.Counter or any other internal detail like that. That's not a good strategy for picking names in computer programming. The name of a function should certainly not be tied to an internal implementation detail (use Counter to implement, so let's name it "Count"?). Something that asserts the equality of two collections of elements is not rocket science and does not deserve an ambiguous name. "Count" is simply too ambiguous in this case.
msg266166 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-23 17:02
Vitaly: if you can come up with a name we agree is more descriptive than the current one by a non-trivial margin, we will be happy to listen.  assertFrequencyCountsEqual is not sufficiently better.  (Personally, I would not know what that function did by reading the name.)
msg266167 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-05-23 17:19
My first expectation for this function was assertUnorderedEqual, but I want to avoid problems with renaming (and coexisting of three names of for the same function), and I vote for status quo.
msg266173 - (view) Author: Vitaly (vitaly) Date: 2016-05-23 18:53
By leaps and bounds, I like assertUnorderedEqual versus assertCountEqual, which is terribly misleading. The first, and simplest, thing that comes to my mind from the word Count by itself is the count of all elements in a sequence (i.e., its length), certainly not frequency count.

I am also happy with the status quo of assertItemsEqual, but I have to agree that assertUnorderedEqual removes any ambiguity that assertItemsEqual purportedly suffers from. Thank you for suggesting assertUnorderedEqual.
msg266184 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2016-05-23 20:49
I'm not against adding a new name if it makes glorious sense, but we should not remove the old names from unittest as that causes unnecessary pain (based on past experience).

assertCountEqual does make sense in terms of the "equivalent to" context from the docs.  Thought I agree with you, its meaning is generally not obvious and must be looked up to be understood.

assertUnorderedEqual is a reasonable name, but I don't find significantly better than assertCountEqual from a "never read the docs, just reading the code" understandability point of view.  It makes me wonder "unordered what?"

that's a vote of -0 for the status quo.
msg266186 - (view) Author: Vitaly (vitaly) Date: 2016-05-23 21:25
When I read "Unordered", it makes me think of collections, including sequences and sets.
msg266188 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-23 21:29
Heh.  We could call it 'assertQuotientSetEqual', but most people would have to look that up (I did, to find it). 'assertEquivalenceClassesEqual' is a bit better, but probably still not clear without looking it up (or being a mathematician).
msg266189 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-23 21:30
And it suffers the same problem as 'unordered', or even more so, as it implies sets, but we aren't dealing with python sets.

See why this is so tough? :)
msg266190 - (view) Author: Vitaly (vitaly) Date: 2016-05-23 21:36
Why do you say that "we aren't dealing with python sets"? Try:

import unittest as u
class Test(u.TestCase):
    def test_equal_count_of_same_elements(self):
        self.assertItemsEqual(set([1,2,3]), set([1,2,3]))

    def test_equal_count_of_different_elements(self):
        self.assertItemsEqual(set([1,2,3]), set([1,2,4]))

    def test_different_count(self):
        self.assertItemsEqual(set([1,2,3]), set([1,2,3,4]))
msg266191 - (view) Author: Vitaly (vitaly) Date: 2016-05-23 21:39
$ python 
FAIL: test_different_count (__main__.Test)
Traceback (most recent call last):
  File "", line 12, in test_different_count
    self.assertItemsEqual(set([1,2,3]), set([1,2,3,4]))
AssertionError: Element counts were not equal:
First has 0, Second has 1:  4

FAIL: test_equal_count_of_different_elements (__main__.Test)
Traceback (most recent call last):
  File "", line 8, in test_equal_count_of_different_elements
    self.assertItemsEqual(set([1,2,3]), set([1,2,4]))
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
First has 0, Second has 1:  4
msg266192 - (view) Author: Vitaly (vitaly) Date: 2016-05-23 21:40
The preceding results are via Python 2.7.10
msg266195 - (view) Author: Vitaly (vitaly) Date: 2016-05-23 21:46
Same results on's Python 3.5.1 shell:
>>> class Test(u.TestCase):
...     def test_equal_count_of_same_elements(self):
...         self.assertCountEqual(set([1,2,3]), set([1,2,3]))
...     def test_equal_count_of_different_elements(self):
...         self.assertCountEqual(set([1,2,3]), set([1,2,4]))
...     def test_different_count(self):
...         self.assertCountEqual(set([1,2,3]), set([1,2,3,4]))
>>> u.main()
FAIL: test_different_count (__main__.Test)
Traceback (most recent call last):
  File "<stdin>", line 7, in test_different_count
AssertionError: Element counts were not equal:
First has 0, Second has 1:  4

FAIL: test_equal_count_of_different_elements (__main__.Test)
Traceback (most recent call last):
  File "<stdin>", line 5, in test_equal_count_of_different_elements
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
msg266196 - (view) Author: Vitaly (vitaly) Date: 2016-05-23 21:48
With missing last line, this time:

FAIL: test_equal_count_of_different_elements (__main__.Test)
Traceback (most recent call last):
  File "<stdin>", line 5, in test_equal_count_of_different_elements
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
First has 0, Second has 1:  4
msg266197 - (view) Author: Vitaly (vitaly) Date: 2016-05-23 21:50
I think that assertUnorderedEqual would contrast nicely with assertSequenceEqual
msg266200 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2016-05-23 22:28
assertUnorderedSequenceEqual would make more sense to me given the natural relation to assertSequenceEqual.

We aren't dealing with sets (though sets are valid sequences) as this method specifically does not require sequence items to be hashable.  Explicitly putting the word sequence in the name makes that more clear.
msg266201 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-23 22:37
how about assertSequenceEqualUnordered
msg266207 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-05-23 23:52
msg266208 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2016-05-23 23:56
assertSequenceEqualUnordered also works R. David.  I was going to suggest that as well but edited it out to keep my suggestion simpler. :)

I don't like the assertMultisetEqual suggestion as this is most notably an api having nothing to do with sets.

msg266210 - (view) Author: Vitaly (vitaly) Date: 2016-05-24 00:11
assertSequenceEqualUnordered is not a good fit, because it doesn't follow the de facto naming convention, whereby "Equal" should be the suffix.

Also assertSequenceEqualUnordered would be considered an oxymoron, since the word "Sequence" implies ordered, while "Unordered" is the opposite. It's like saying "ordered unordered collection".

My vote (if I had one) is still with assertUnorderedEqual. I think that from the word "Unordered" it's a reasonable leap that it refers to an unordered collection of elements, and it would be easy to remember.
msg266235 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-05-24 06:37
Further churning of the names will cause more harm than good.  I recommend closing this (to end the bike-shedding and the stream of superlatives from the OP).  This ship has sailed and users are already relying on the published API.

Foord: "In the absence of a *dramatically* better name leave it alone."
Storchaka: "I vote for status quo."
Murray:  "I say leave well enough alone unless someone comes up with a simply brilliant better name."
Smith: "I'm not against adding a new name if it makes glorious sense, but we should not remove the old names from unittest as that causes unnecessary pain (based on past experience)."

FWIW, most of the suggestions in this issue would not help with a "never read the docs, just reading the code" kind of user.  Without biasing the result,  ask other Python user's to guess what "assertItemsEqual" or "assertElementsEqual" do, and see whether they correctly deduce that it tests the equality of two unordered multisets formed from two input iterables.
msg266244 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-24 11:41
Agreed.  Time to close the issue.  If someone wants to do actual testing as Raymond suggests, and finds a name that actually works, they can either reopen this with a report or open a new issue.
msg318434 - (view) Author: Alden (aldencolerain) Date: 2018-06-01 17:09
I think we need to re-open this issue.  I have done a poll of a number of python developers and every developer I talked to said they initially thought this function "assertCountEqual" asserts that the count is equal. Probably because that's exactly what the words mean. I think most people in this discussion agree that the name is not ideal, but how did we end up picking one that explicitly says something completely incorrect?  Not only that but we broke backward compatibility for a name that is significantly worse than the original.

If you asked any colleague or developer on the street that isn't a python 3 user what "assert count equal" would do when provided with two lists. I would be amazed if anyone said something other than "checks that the two lists store the same number of elements".  I have asked everyone I know and no one has said anything different.

assertItemsEqual - Most people get this correct, some people think it also checks order. This confusion actually isn't that common because people first learn the function that DOES check order. (better)

assertFrequencyCountsEqual - Most people aren't sure what this does and would be need to look this up. (better)

assertElementCountsEqual - Seems like it checks the count of a list, but leaves you with some uncertainty. (not great, but better)

assertCountEqual and assertCountsEqual - Everyone i spoke to thought this asserted that number of elements in the collections were equal. Total certainty about the wrong functionality.

Explicit is better than implicit.
  * This name is not explicit it implies a completely different behavior.
Readability counts.
  * The words of this function literally mean something else.
Practicality beats purity.
  * Users not in the Python ivory tower immediately recognize this function name as something else. 
In the face of ambiguity, refuse the temptation to guess.
  * This name is not just ambiguous it is misleading and makes users guess and guess incorrectly.
If the implementation is hard to explain, it's a bad idea.
  * If we can't name this function correctly, maybe it's a bad idea?
Now is better than never.
  * This was a mistake and its better to correct it now than let it live on for another two years.
msg318491 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2018-06-02 08:40
So, I think we're in a local minima here.

As I said earlier, neither the old nor new names really grab me, and I think everyone has aknowledged that the new name is -at best- confusing. We don't need *any more discussion* about that. The question is how to fix it without yet more rounds of 'well this is confusing so lets change it again'.

I want to suggest some basic criteria for a dramatically better name, just to unblock this.

- follow the existing assert<modifiers><relation> naming convention
- be short enough to be comfortably usable
- pass some user testing: do some lightning talks. Or ask on twitter for folk to tell you what the proposed name does without any hints.

- follow up here with how you tested and the name you've chosen based on that testing.

- we'll then do a straw poll amongst a few committers - me and michael at a minimum, and advise on go/nogo.

Once thats done I'll happily review a patch that adds a new, better name as an alias, and doesn't deprecate the existing one.

I'm leaving the bug in rejected status, because at this point there is nothing any committers seem to have appetite/energy to do: same as per
msg346684 - (view) Author: Thomas Grainger (graingert) * Date: 2019-06-26 21:33
How about assertIsPermutation?
msg352477 - (view) Author: Thomas Grainger (graingert) * Date: 2019-09-15 15:04
I think assertPermutation (without the "is") would be the best name
msg352556 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2019-09-16 16:39
I like assertPermutation (with or without the Is, slight preference for without).
msg352648 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2019-09-17 16:15
In msg266115, Robert Collins suggested  "add a different name and deprecate assertCountEqual".

In msg266184, Gregory Smith said "not against adding a new name if it makes glorious sense, but we should not remove the old names from unittest as that causes unnecessary pain (based on past experience)."

Others suggested status quo.

In msg352556, Michael Ford said "I like assertPermutation", but did not reopen the issue.

Coming at this fresh, via the PR that patches idlelib, my first thought was that assertCountEqual meant assertEqual(len(a), len(b)).  So the issue seems real.  assertPermutation is much better to me and I would like it added.

In unittest/, PR 16228 renames assertCountEqual to assertPermutation and adds assertCountEqual as an alias, with no plan for deprecation and removal, as eventually done with other duplicates.

However, the PR also immediately renames all instances of assertCountEqual in the stdlib.  Perhaps 1/4 of these are in idlelib tests.  Much as I prefer the new name, this is unacceptible as it immediately makes backporting test changes in these areas (and I plan to make some) a manual process.  So I don't want IDLE tests renamed until 3.8 is off maintenance and the name change can be made in all maintenance versions at once.

I leave it to the rest of you to decide on the rest of the stdlib.
msg352926 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2019-09-21 05:52
FWIW "assertMultiSetEqual" may be better than "assertPermutation".  The issue with the latter is that distinct but equal values may appear on both sides, so it isn't really a permutation.

   # These don't look like permutations at all
   # but they are equivalent multisets
   assertPermutation([Decimal(3), 5, Fraction(12, 4)], [3.0, 3, Fraction(15, 3)])
msg352938 - (view) Author: Thomas Grainger (graingert) * Date: 2019-09-21 09:55
While it may not appear to be a permutation, python already considers it one:

    graingert@onomastic:~$ cat 
    import itertools
    import unittest
    from decimal import Decimal
    from fractions import Fraction

    class TestAssertPermutation(unittest.TestCase):
        def assertPermutation(self, a, b):
            return self.assertIn(tuple(a), itertools.permutations(b))

        def test_do_not_look_like_permutations(self):
                [Decimal(3), 5, Fraction(12, 4)], [3.0, 3, Fraction(15, 3)]

    if __name__ == "__main__":
    graingert@onomastic:~$ python3 -v
    test_do_not_look_like_permutations (__main__.TestAssertPermutation) ... ok

    Ran 1 test in 0.000s

msg352950 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2019-09-21 20:18
I like using 'multiset', but I think 'assertMultisetEqual', proposed by Martin Panter in msg266207, is better than assertMultiSetEqual, as it does not imply the existence of a class 'MultiSet'.

Raymond's comment "distinct but equal values may appear on both sides, so it isn't really a permutation" turns on the ambiguity of 'same element' in the assertCoultEqual definition.  The doc never says explicitly that it means same by equality ('==') regardless of class, rather than same by equality within a class, which one might assume for 'permutation of values', or same by identity ('is'), which would be needed for 'permutation of objects'.  I think it should what same means here.

Gregory Smith msg266208 objects to a name containing 'set' because "this is most notably an api having nothing to do with sets".  However, the short definition of the assertion, "a and b have the same elements in the same number, regardless of their order" *is* a definition of multiset equality.  The assertion looks at both collections as multisets.

Unlike R. David Murray msg266153, I see a difference between 'count' and 'counts'.  The former can only mean comparing one count for each collection, the number of items.  The latter could mean the same, but could also mean comparing multiple counts for each collection, as is the case.

RDM goes on to claim that 'count' is correct because the function's doc defines it in terms of itertools.count.  It actually defines it in terms of collections.Counter, which would suggest, using the same logic, 'assertCounterEqual' or assertCountersEqual.  Since Counter implements the mathematical idea of 'multiset' and "is similar to bags or multisets in other languages", we get to 'assertMultisetEqual' as the less Python-specific name.

[I am puzzled about a couple of things.  The doc says "Equivalent to: assertEqual(Counter(list(first)), Counter(list(second)))
but works with sequences of unhashable objects as well."  That expression *is* the current implementation.

1. It seems that the 'list' call should be irrelevant.
2. Counter calls fail  with iterables of unhashable objects.  Why not the overall expression?]
msg352953 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-09-21 20:47
> 1. It seems that the 'list' call should be irrelevant.

It is relevant. Counter({1: 2}) != Counter(list({1: 2})).
msg376740 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-09-11 22:05
Issue 38240 was closed as a duplicate of this.  After reconsidering, I agree with leaving the name alone.  Changing test assertXXX method names is a big nuisance, which we have done enough of.

If one is using IDLE,
>>> unittest.TestCase.assertCountEqual(
displays a boxed calltip with the signature and the two line summary that seems clear enough to me.  Good names are good; so are good docstring summaries.
|(self, first, second, msg=None)                                       |
|Asserts that two iterables have the same elements, the same number of |
|times, without regard to order.                                       |
Date User Action Args
2020-09-11 22:05:33terry.reedysetmessages: + msg376740
2019-09-21 20:47:44serhiy.storchakasetmessages: + msg352953
2019-09-21 20:18:39terry.reedysetmessages: + msg352950
2019-09-21 09:55:01graingertsetmessages: + msg352938
2019-09-21 05:52:06rhettingersetmessages: + msg352926
2019-09-20 21:58:32ammar2linkissue38240 superseder
2019-09-17 16:15:15terry.reedysetnosy: + terry.reedy

messages: + msg352648
versions: + Python 3.9, - Python 3.6
2019-09-17 11:05:25graingertsetpull_requests: + pull_request15826
2019-09-16 16:39:19michael.foordsetmessages: + msg352556
2019-09-15 15:04:26graingertsetmessages: + msg352477
2019-06-26 21:33:15graingertsetnosy: + graingert
messages: + msg346684
2018-06-02 08:40:21rbcollinssetmessages: + msg318491
2018-06-01 17:09:43aldencolerainsetnosy: + aldencolerain
messages: + msg318434
2016-05-24 11:41:39r.david.murraysetstatus: open -> closed
resolution: rejected
messages: + msg266244

stage: resolved
2016-05-24 06:37:27rhettingersetmessages: + msg266235
2016-05-24 00:11:20vitalysetmessages: + msg266210
2016-05-23 23:56:41gregory.p.smithsetmessages: + msg266208
2016-05-23 23:52:36martin.pantersetnosy: + martin.panter
messages: + msg266207
2016-05-23 22:37:13r.david.murraysetmessages: + msg266201
2016-05-23 22:28:59gregory.p.smithsetmessages: + msg266200
2016-05-23 21:50:23vitalysetmessages: + msg266197
2016-05-23 21:48:28vitalysetmessages: + msg266196
2016-05-23 21:46:44vitalysetmessages: + msg266195
2016-05-23 21:40:49vitalysetmessages: + msg266192
2016-05-23 21:39:37vitalysetmessages: + msg266191
2016-05-23 21:36:15vitalysetmessages: + msg266190
2016-05-23 21:30:53r.david.murraysetmessages: + msg266189
2016-05-23 21:29:50r.david.murraysetmessages: + msg266188
2016-05-23 21:25:53vitalysetmessages: + msg266186
2016-05-23 20:49:25gregory.p.smithsetmessages: + msg266184
2016-05-23 19:23:28serhiy.storchakasetnosy: + georg.brandl, rhettinger, gregory.p.smith
2016-05-23 18:53:10vitalysetmessages: + msg266173
2016-05-23 17:19:36serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg266167
2016-05-23 17:02:22r.david.murraysetmessages: + msg266166
2016-05-23 16:39:45vitalysetmessages: + msg266164
2016-05-23 16:03:40michael.foordsetmessages: + msg266160
2016-05-23 14:49:03r.david.murraysetnosy: + r.david.murray
messages: + msg266153
2016-05-23 06:01:21vitalysetmessages: + msg266123
2016-05-23 05:31:53vitalysetmessages: + msg266121
2016-05-22 23:03:20rbcollinssetmessages: + msg266115
2016-05-21 06:25:26SilentGhostsetnosy: + rbcollins, ezio.melotti, michael.foord

type: behavior
versions: - Python 3.3, Python 3.4, Python 3.5
2016-05-21 00:08:25vitalysetmessages: + msg265984
2016-05-20 23:53:00vitalycreate