homepage

Now that deprecations are silent by default it would be much less intrusive to deprecate unittest.TestCase.assertEqual
We have a persistent issue in the Python test suite of developers using assertEquals when we have standardised on assertEqual. In regrtest we could patch TestCase.assertEquals to raise a (hopefully helpful) error. That'll stop the blighters!

What about the other duplicate pairs with a preferred choice?
Is there too much use of the deprecated choice?

If you are talking about assertNotEquals, assertAlmostEquals, and assertAlmostNotEquals they should go as well (I didn't even know they existed). assert_ is probably used more often, but I'd deprecate it too.
Note that in the 2.7 and 3.2 doc assert_ is already marked as deprecated, and the other methods are not documented.
The plan is:
 1) replace all the occurrences of assertEquals, assertNotEquals, assertAlmostEquals, assertAlmostNotEquals, assert_ in the Python test suite with assertEqual, assertNotEqual, assertAlmostEqual, assertAlmostNotEqual, assertTrue;
 2) deprecate assertEquals, assertNotEquals, assertAlmostEquals, assertAlmostNotEquals, assert_;
 3) patch regrtest.py to raise an error when these methods are used, in order to avoid that they sneak in again in the Python test suite.

These synonyms have been around a very long time and many test suites have one or the other or both. Nothing good can come from breaking those existing test suites. We don't need to harm our users just to accommodate a stylistic preference.

We aren't talking about *removing* these methods from unittest - but now that we have standardised on assertEqual for the Python test suite it is annoying (particularly for Ezio who changes) when *new* tests are checked in using the old (deprecated-but-not-actually-deprecated) methods.
As deprecation warnings are now silent by default deprecating these old methods would only affect developers who run their tests specifically looking for information like this. Making the change is also a single "search and replace" across a code-base, so not a difficult change.
Actually whether or not we deprecate these methods in unittest itself is one question (I'm only +0 on that - I don't really care if they live for ever in general and Raymond's response can be read as a strong +1 for that). What Ezio *really* wants is to have these methods raise errors if used during *regrtest* runs, so that core-Python developers no longer use them. That I am fine with - although we would need some way for the tests for these methods themselves to actually run.

What a tremendous waste of time and inane exercise. AFAICT, this is a zero value add.
Also, we try to avoid these sort of search-and-replace exercises because 1) they are not part of holistic refactoring (Guido's term for making changes while you're working on a particular module, not whole-sale sweep), 2) they risk getting it wrong and 3) it obfuscates the "svn ann" output making it more difficult to tell who did the original work.
The goal is of "have these methods raise errors if used during *regrtest* runs, so that core-Python developers no longer use them" is a worthless one. Raising errors for this sort of thing wastes the time of developers who are trying to get real work done.
-1

It's not really a waste of time, since it's just a find and replace and I already have a patch ready. I also believe that there are valid reasons to do it.
When I started learning about unittest, I clearly remember asking myself if I should have used "assertEqual" or "assertEquals" and thought that two different methods with two different names probably did two different things (TMBOOWTDI). I also remember thinking that "assertEquals" must have been a "plural" version of "assertEqual" able to accept more than two argument at once (i.e. assertEquals(a, b, c, d) -> a == b == c == d).
I can imagine people finding it in some code (possibly in the Python test suite), thinking that is a typo, being confused because the documentation doesn't mention it, wonder how the test can pass if they use a "ghost" method, asking themselves if the code is really executed and so on.
Since we are moving away from these methods, it's annoying seeing people using them and reintroduce them in the Python test suite and that wastes time during the commit reviews for the reviewer and for the committer that has to fix it and merge the fix.
This said, it could be enforced both in regrtest or with a commit hook.

Please don't pursue this further. It does not matter at all whether developers use assertEqual or assertEquals. That is no more than a stylistic preference. I do not want a commit hook, or for developer patches to be edited, or for there to be as assertEquals police squad. Please focus on something that is not superficial.

Well, there is *some* value in stylistic consistency. If it didn't matter at all then Guido wouldn't have instigated the deprecation of assertEquals and assert_ and standardised on assertEqual (which he did during the sprints at PyCon 2009). Either we stick with that or we don't.

See also #5846 

The attached patch addresses the point 1) of msg113147.

I uploaded the patch on http://codereview.appspot.com/3232042 too.

Committed in r86596.

I merged the patch on 3.1 in r86629 and on 2.7 in r86637.
I would like to propose the following deprecation schedules for the deprecated fail* and assert* methods:
* for the fail* methods:
 add a DeprecationWarning in 3.1 (done in r74096);
 remove them in 3.3 (see msg65142);
* for the assert* methods:
 add a DeprecationWarning in 3.2;
 leave them around for a few more versions;
These deprecations should be documented on whatsnew3.2 too.

The attached patch (issue9424-2.diff) addresses the point 2) of msg113147.

Committed in r86690 on py3k, blocked in r86691 and r88692 on 3.1/2.7.

Instead of turning warnings on by default in regrtest, it would be better to do it directly in unittest. I'll close this and open a new issue for that.

See #10535.

The fail* methods and assertDictContainsSubset will be in 3.3 too, see #11282. There is no version planned for their removal yet.
assertSameElements is gone from 3.3.

It probably would have been okay to remove assertDictContainsSubset which had nearly zero uptake (according to Google's code search). That's probably because it addresses an uncommon use case, because it was only recently introduced, and because its arguments were in the wrong order.
That situation is much different that assertEquals and friends that have been around for a long time.
I don't care much how this gets resolved; just wanted to point-out that there is much less of a reason to keep assertDictContainsSubset..

Can we remove these aliases in Python 3.10?
(See also #41165)