Ezio Melotti <ezio.melo...@gmail.com> added the comment: * I would leave assert<type>Equal documented and specify that they should be called directly only if the type should be checked, otherwise (if the type doesn't matter or it's already tested elsewhere) using assertEqual is enough (see also the suggestions in msg120124). -0.5 about dedocumenting, +1 on better documentation, possibly in an "advanced" section of the doc (I also find useful to know how assertEqual works and that I can register new functions like assert<type>Equal).
* assertLT and friends wouldn't match with assertEqual and assertNotEqual (assertEQ, assertNE?). Also these names don't seem more obvious or readable than assertLess, and will just add confusion and duplication of names, so -1. * FWIW I like 'Regex' more than 'Regexp' too, assuming that it's worth renaming these methods and deprecate the old names (they are already in 2.7). Having a 'Match' or 'Search' suffix might clarify what the method does -- if it does what it says. +0 on the renaming (and +1 to 'Regex' if the rename happens). * as I said on IRC, assertItemsEqual provides an useful functionality, and even if the name is not 100% clear, I'd rather double-check the doc than having to reimplement the functionality myself (or having a clumsy long-but-clear name). -1 on the removal, +1 on better documentation/performance. * I think assertIsInstance is fine, however I wonder why the opposite is not assertIsNotInstance. Anyway it's probably not worth creating more confusion and adding new names just to change the spelling (they are in 2.7 too). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10273> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
