[issue2249] To document "assertTrue" in unittest

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue2249] To document "assertTrue" in unittest

Georg Brandl <[EMAIL PROTECTED]> added the comment: Okay, I give in :) Committed as r61329. -- resolution: wont fix -> fixed status: pending -> closed __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2249] To document "assertTrue" in unittest

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: Just to make the story complete, it should be mentioned that assertFalse/True were added because these are the names used by JUnit: r34209 | purcell | 2003-09-22

[issue2249] To document "assertTrue" in unittest

Steve Purcell <[EMAIL PROTECTED]> added the comment: +1 for applying Alexander's patch, then; I'll leave the decision to a current committer. __ Tracker <[EMAIL PROTECTED]> __

[issue2249] To document "assertTrue" in unittest

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: FWIW, grepping through Lib/test reveals the following statistics: assertFalse: 83 assertTrue: 97 failUnless: 684 assert_: 1977 Not having assertTrue/assertFalse methods in the Library Reference does not discourage people from using th

[issue2249] To document "assertTrue" in unittest

Jesús Cea Avión <[EMAIL PROTECTED]> added the comment: I noted the issue while working in bsddb3 module. If failed in python2.3 because some tests were using "assertTrue". I had to dig where that method came from (time lost!) and found that a) it was added in python 2.4 and b) it is not documente

[issue2249] To document "assertTrue" in unittest

Steve Purcell added the comment: I could be convinced either way here, and Georg & Raymond always have excellent judgement. My personal inclination would probably be to add the documentation for assertTrue() and also assertFalse(), since their naming is symmetrical with that of assertEqual()

[issue2249] To document "assertTrue" in unittest

Georg Brandl added the comment: I agree with Raymond. Having three names for a function is even more un-Zen than two. Also, I can't see wha'ts clearer in assertTrue in comparison with assert_. -- resolution: -> wont fix status: open -> pending __ Tracke

[issue2249] To document "assertTrue" in unittest

Raymond Hettinger added the comment: I prefer that this remain undocumented. The published API is already too fat. This would make it fatter without adding functionality. -- nosy: +rhettinger __ Tracker <[EMAIL PROTECTED]>

[issue2249] To document "assertTrue" in unittest

Changes by Benjamin Peterson: -- nosy: +purcell __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue2249] To document "assertTrue" in unittest

Changes by Jesús Cea Avión: -- versions: +Python 2.4 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue2249] To document "assertTrue" in unittest

New submission from Jesús Cea Avión: Python 2.4 and 2.5 unittest includes a "assertTrue" method undocumented. Document it. It is the same method as "assert_" and "failUnless", but the name seems clearer. -- assignee: georg.brandl components: Documentation messages: 63347 nosy: georg.bra