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 ChrisBarker
Recipients ChrisBarker, Pam.McANulty, berker.peksag, ezio.melotti, mark.dickinson, michael.foord, r.david.murray, rbcollins, rhettinger
Date 2016-06-21.23:55:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1466553326.29.0.789274471457.issue27198@psf.upfronthosting.co.za>
In-reply-to
Content
Did my comments not get posted, or are they not being read? Anyway:

Could we keep the issues separate here?

1) If you don't like the name, propose another name -- no none has defended this name since an objection was first raised. I"m sure we can find one that would work, if we want to add it.

2) regardless of the original intent, the current API:
 - requires fairly substantial effort to write a new assertion, whether as a method or a function. Thus it's a good idea to provide generally useful ones
 - has a bunch of assert methods, many of which are no more commonly useful than the proposed method.

So adding this is very much in keeping with the current API.

However, it seems there is much resistance to adding new asserts to the base TestCase. Fine. I have trouble defending that as I don't like the API anyway (and yes, of course, it comes from Java -- that's actually the source of the problem :-) )

But: this is a generally useful and non-trivial assert (indeed, as way too many people are confused about floating point, I think it's pretty critical to provide appropriate tools -- and assertAlmostEqual is NOT the appropriate tool in many cases.

So how to provide this? Options:

1) Robert suggested a stand alone function -- sure, but where to put it?

2) Apparently there is a movement afoot to add a mixin with extra stuff -- sure, that would be fine, but only if there actually is such a mixin.

3) add the functionality to assertAlmostEqual, with a new optional parameter -- I suggested this a few comments back, and have had no feedback. (that at least avoids bike shedding the name...)

My key points:

1) This is generally useful and non-trivial -- so would be good to add to the stdlib.

2) it should be discoverable -- as pointed out, folks have not been clamoring for it -- which means they won't know to go digging for it -- they should find it easily (as many folks will use assertAlmostEqual, when they would be better served by this)

which leaves us with adding to a library of functions or a mixin, only if such a thing will actually be build and documented, with more than one function it it :-)

or adding to assertAlmostEqual.

Feedback on this?

(note: adding assertClose as is now off the table, no more need to argue about that)
History
Date User Action Args
2016-06-21 23:55:26ChrisBarkersetrecipients: + ChrisBarker, rhettinger, mark.dickinson, rbcollins, ezio.melotti, r.david.murray, michael.foord, berker.peksag, Pam.McANulty
2016-06-21 23:55:26ChrisBarkersetmessageid: <1466553326.29.0.789274471457.issue27198@psf.upfronthosting.co.za>
2016-06-21 23:55:26ChrisBarkerlinkissue27198 messages
2016-06-21 23:55:25ChrisBarkercreate