You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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_.
purcell commented on Mar 8, 2008
purcellmannequin
Mannequin
More actions
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() etc. I think plenty of people are using
those functions anyway, judging by emails I receive, and I'm not sure
that leaving the function undocumented addresses the issue of the
(admittedly) sprawling API.
(I think Fred Drake put together the documentation originally; I don't
recall any particular discussion about which aliases to document and
which to leave out.)
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 documented.
Since "assertTrue" use is "in the wild", being undocumented is a
inconvenience. Moreover, I think "assertTrue" is far more intuitive and
cleaner than "assert_" or "failUnless". A personal impression, of
course. Symmetric with "assertEqual" and so, would be nice.
Not having assertTrue/assertFalse methods in the Library Reference does
not discourage people from using them given that they show up without
any warning in help(). (Moreover, assertTrue shows up before assert_.)
I would say it should be documented. After all it would only take a two
line patch (see attached).
(I agree with OP that assertTrue is clearer than assert_ . Although I
know that '_' is only there to avoid a conflict with the assert keyword,
assert_ always stand out as different from the other TestCase methods.)
purcell commented on Mar 9, 2008
purcellmannequin
Mannequin
More actions
+1 for applying Alexander's patch, then; I'll leave the decision to a
current committer.
Activity
jcea commentedon Mar 7, 2008
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.
rhettinger commentedon Mar 8, 2008
I prefer that this remain undocumented. The published API is already
too fat. This would make it fatter without adding functionality.
birkenfeld commentedon Mar 8, 2008
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_.
purcell commentedon Mar 8, 2008
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() etc. I think plenty of people are using
those functions anyway, judging by emails I receive, and I'm not sure
that leaving the function undocumented addresses the issue of the
(admittedly) sprawling API.
(I think Fred Drake put together the documentation originally; I don't
recall any particular discussion about which aliases to document and
which to leave out.)
-Steve
jcea commentedon Mar 9, 2008
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 documented.
Since "assertTrue" use is "in the wild", being undocumented is a
inconvenience. Moreover, I think "assertTrue" is far more intuitive and
cleaner than "assert_" or "failUnless". A personal impression, of
course. Symmetric with "assertEqual" and so, would be nice.
I won't insist, in any case :-)
abalkin commentedon Mar 9, 2008
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 them given that they show up without
any warning in help(). (Moreover, assertTrue shows up before assert_.)
I would say it should be documented. After all it would only take a two
line patch (see attached).
(I agree with OP that assertTrue is clearer than assert_ . Although I
know that '_' is only there to avoid a conflict with the assert keyword,
assert_ always stand out as different from the other TestCase methods.)
purcell commentedon Mar 9, 2008
+1 for applying Alexander's patch, then; I'll leave the decision to a
current committer.
abalkin commentedon Mar 9, 2008
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 07:08:12 -0400 (Mon, 22 Sep 2003) | 11
lines
..
birkenfeld commentedon Mar 9, 2008
Okay, I give in :) Committed as r61329.