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.

Author ezio.melotti
Recipients ezio.melotti, michael.foord, rhettinger, terry.reedy
Date 2010-08-12.06:46:08
SpamBayes Score 1.3765232e-06
Marked as misclassified No
Message-id <1281595571.7.0.572663262812.issue9424@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-08-12 06:46:11ezio.melottisetrecipients: + ezio.melotti, rhettinger, terry.reedy, michael.foord
2010-08-12 06:46:11ezio.melottisetmessageid: <1281595571.7.0.572663262812.issue9424@psf.upfronthosting.co.za>
2010-08-12 06:46:09ezio.melottilinkissue9424 messages
2010-08-12 06:46:08ezio.melotticreate