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 brett.cannon, ezio.melotti, michael.foord, pitrou, r.david.murray, rhettinger
Date 2010-11-04.11:52:59
SpamBayes Score 1.1179484e-09
Marked as misclassified No
Message-id <1288871582.51.0.0557967608571.issue10273@psf.upfronthosting.co.za>
In-reply-to
Content
It should be noted that, if we re-use assertSameElements, the default behavior should be preserved for compatibility with 3.1, and that is different (and possibly less useful) than the one of assertItemsEqual. Ambiguities could be solved easily specifying the args explicitly every time though.

Regarding assertLT I'm still -1. The current names are imho the best compromise between being short and descriptive.
They also match nicely assertEqual (assertLT <-> assertEQ; assertLessThan <-> assertEqualTo; but assertLess <-> assertEqual).
Also it might not be immediately obvious what assertGE does, if one is not familiar with the special methods or if taken out of context (it's easy to recognize it if it's together with assertLT/LE/GT, but alone might just look a specialized method with a bad name).
Moreover people who are used to the current spelling will have to notice the change, note that one name is now deprecated, update their code, remember if the correct name is assertLess or assertLT, wonder if assertEqual has been deprecated in favor of assertEQ too, remember the version where the name changed (e.g. if they try assertLT on 3.1 it won't work) and so on.
History
Date User Action Args
2010-11-04 11:53:02ezio.melottisetrecipients: + ezio.melotti, brett.cannon, rhettinger, pitrou, r.david.murray, michael.foord
2010-11-04 11:53:02ezio.melottisetmessageid: <1288871582.51.0.0557967608571.issue10273@psf.upfronthosting.co.za>
2010-11-04 11:53:00ezio.melottilinkissue10273 messages
2010-11-04 11:52:59ezio.melotticreate