Florent Xicluna <florent.xicl...@gmail.com> added the comment:
Gregory P. Smith wrote:
> Looking through the thousands of uses of assertSameElements in our internal
> code base at work I see many uses of it that are likely not hashable items
> in the sequences being compared.
The method assertSameElements will still support unhashable elements.
In this case the fixed behaviour will be harmless for your code base,
like for many other users. Example with unhashable entries:
assertSameElements(list([3], [None], [3]), tuple([None], [3], [3]))
==> pass
assertSameElements(list([3], [None], [3]), tuple([None], [None], [3]))
==> fails
The patch only fix the 2nd case here. Before the patch it didn't fail on
this case.
I still don't see real cases where we need that [0, 0, 1] and [0, 1, 1]
compare equal.
And this enhancement will be less surprising for the user.
Currently, if someone uses "assertSameElements" it could expect that it
fails when the count of elements is not the same. And it will never notice
that he's wrong and that his unittest have a flaw.
In a sense, it is not helpful for the end user to preserve the current
behaviour. There's a risk that tests will not fail when they should.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7832>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
