Guido van Rossum <gu...@python.org> added the comment: The naming pattern (assertListEqual, assertDictEqual, etc.) is pretty easy to pick up so I don't think the addition of several new methods is a big deal. Making assertEqual() do the right thing all the time is hard if there are subclasses that might override __eq__ or do other tricks, so I am glad that Greg only put the simplest test possible in assertEqual. And I would still want to have a way to explicit *disable* that in case I am comparing containers with millions of items. New assertions like assertSameElements, assertDictContainsSubset or assertMultilineEqual are not things that can be guessed, and they *are* useful.
The names are also trivial to understand when reading tests that someone else wrote, so I am not so worried about the cognitive effort. I would rather start deprecating the fail* variants and use assertTrue in favor of assert_, and settle the question of whether to prefer assertEqual vs. assertEquals (the former, please). Finally, a simple refactoring of the code might be helpful where the preferred name for each function is actually the name used in the 'def' for it, so that tracebacks involving such assertions show the preferred names, and so that their definitions can be found by searching the code for e.g. "def assertEqual". ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue2578> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com