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.

Title: Deprecate assertEquals, assertNotEquals, assert_, assertAlmostEquals, assertNotAlmostEquals
Type: Stage: resolved
Components: Versions: Python 3.2
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: ezio.melotti Nosy List: eric.araujo, ezio.melotti, methane, michael.foord, rhettinger, terry.reedy
Priority: low Keywords: patch

Created on 2010-07-30 00:05 by michael.foord, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
issue9424.diff ezio.melotti, 2010-11-20 15:30 Patch to convert deprecated methods in the stdlib test suite
issue9424-2.diff ezio.melotti, 2010-11-21 20:36 Patch to add a DeprecationWarning to the deprecated assert* methods
Messages (21)
msg112025 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2010-07-30 00:05
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!
msg113130 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-08-06 19:55
What about the other duplicate pairs with a preferred choice?
Is there too much use of the deprecated choice?
msg113147 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2010-08-07 02:19
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 to raise an error when these methods are used, in order to avoid that they sneak in again in the Python test suite.
msg113639 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-08-11 22:44
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.
msg113644 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2010-08-11 23:44
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.
msg113657 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-08-12 06:15
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.

msg113658 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2010-08-12 06:46
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.
msg113660 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-08-12 07:06
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.
msg113695 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2010-08-12 18:05
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.
msg115832 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-09-08 00:36
See also #5846
msg121665 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2010-11-20 15:30
The attached patch addresses the point 1) of msg113147.
msg121669 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2010-11-20 16:15
I uploaded the patch on too.
msg121723 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2010-11-20 19:07
Committed in r86596.
msg121964 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2010-11-21 19:10
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.
msg121982 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2010-11-21 20:36
The attached patch (issue9424-2.diff) addresses the point 2) of msg113147.
msg122120 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2010-11-22 13:11
Committed in r86690 on py3k, blocked in r86691 and r88692 on 3.1/2.7.
msg122410 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2010-11-25 21:58
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.
msg122412 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2010-11-25 22:09
See #10535.
msg132843 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-04-03 15:13
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.
msg132867 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2011-04-03 18:27
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..
msg372803 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2020-07-02 06:18
Can we remove these aliases in Python 3.10?
(See also #41165)
Date User Action Args
2022-04-11 14:57:04adminsetgithub: 53670
2020-07-02 06:18:45methanesetnosy: + methane
messages: + msg372803
2011-04-03 18:27:10rhettingersetmessages: + msg132867
2011-04-03 15:13:14ezio.melottisetmessages: + msg132843
2010-11-25 22:09:26ezio.melottisetmessages: + msg122412
2010-11-25 21:58:35ezio.melottisetstatus: open -> closed
title: Disable unittest.TestCase.assertEquals and assert_ during a regrtest run -> Deprecate assertEquals, assertNotEquals, assert_, assertAlmostEquals, assertNotAlmostEquals
messages: + msg122410

resolution: fixed
stage: needs patch -> resolved
2010-11-22 13:11:48ezio.melottisetmessages: + msg122120
2010-11-21 20:36:46ezio.melottisetfiles: + issue9424-2.diff

messages: + msg121982
2010-11-21 19:10:50ezio.melottisetmessages: + msg121964
2010-11-20 19:07:08ezio.melottisetmessages: + msg121723
2010-11-20 16:15:07ezio.melottisetmessages: + msg121669
2010-11-20 15:31:14ezio.melottisetfiles: + issue9424.diff
keywords: + patch
messages: + msg121665
2010-09-08 00:36:40eric.araujosetmessages: + msg115832
2010-08-21 21:24:57eric.araujosetnosy: + eric.araujo
2010-08-12 18:05:49michael.foordsetmessages: + msg113695
2010-08-12 07:06:23rhettingersetmessages: + msg113660
2010-08-12 06:46:09ezio.melottisetmessages: + msg113658
2010-08-12 06:15:51rhettingersetpriority: normal -> low

messages: + msg113657
2010-08-11 23:45:33michael.foordsettitle: deprecate unittest.TestCase.assertEquals -> Disable unittest.TestCase.assertEquals and assert_ during a regrtest run
2010-08-11 23:44:51michael.foordsetstatus: closed -> open
assignee: rhettinger -> ezio.melotti
resolution: rejected -> (no value)
messages: + msg113644
2010-08-11 22:44:42rhettingersetstatus: open -> closed

nosy: + rhettinger
messages: + msg113639

assignee: ezio.melotti -> rhettinger
resolution: rejected
2010-08-07 02:19:59ezio.melottisetmessages: + msg113147
stage: needs patch
2010-08-06 19:55:07terry.reedysetnosy: + terry.reedy
messages: + msg113130
2010-07-30 00:05:51michael.foordcreate