[Python-Dev] Introducing GSOC student James Pruitt
I am a mentor for a GSOC 2009 student working on a PSF project. His project abstract is "Handling of subprocess async io issues, testing and reimplementing the commands module in terms of subprocess." He has started a blog, http://subdev.blogspot.com/, in which he is providing general information on his GSOC project. In the next few days, he will start a project on google code so that interested parties can help guide his work. I urge anyone interested in the subprocess module to interact with Mr. Pruitt and provide feedback/suggestions/encouragement. Charles R. McCreary ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optional delta argument for assertAlmostEqual
Perhaps not just absolute but relative tolerance, e.g.: def isclose(x, y, rtol=1.e-5, atol=1.e-8): return abs(x-y) <= atol + rtol * abs(y) On Fri, Mar 26, 2010 at 7:59 PM, Michael Foord wrote: > Hello all, > > A user has suggested an optional argument to > unittest.TestCase.assertAlmostEqual for specifying a maximum difference > between the expected and actual values, instead of using rounding. > > This sounds great to me as the default implementation of assertAlmostEqual > has *never* been useful to me (YMMV). In fact one of the first things I do > on setting up a test suite is provide a TestCase that overrides > assertAlmostEqual with an implementation that uses a delta rather than > rounding. > > The implementation would be effectively: > > assert abs(actual - expected) < delta > > This has the advantage that it allows things like: > > self.assertAlmostEqual(timeStamp, expected, > delta=datetime.timedelta(seconds=5)) > > The issue is this would make the signature of assertAlmostEqual (and its > negative counterpart): > > def assertAlmostEqual(self, first, second, places=7, msg=None, delta=None) > > Note that delta comes after msg, which is different to other assert > methods. To put delta before msg would be backwards incompatible with > existing uses passing arguments positionally. In Python 3.2 we can make > delta a keyword argument. Passing both places and delta would be an error > (TypeError). > > Anyway, unless there are strenuous objections I intend to do this. > > All the best, > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > READ CAREFULLY. By accepting and reading this email you agree, on behalf of > your employer, to release me from all obligations and waivers arising from > any and all NON-NEGOTIATED agreements, licenses, terms-of-service, > shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, > non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have > entered into with your employer, its partners, licensors, agents and > assigns, in perpetuity, without prejudice to my ongoing rights and > privileges. You further represent that you have the authority to release me > from any BOGUS AGREEMENTS on behalf of your employer. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/charles.r.mccreary%40gmail.com > -- Charles McCreary P.E. CRM Engineering 903.643.3490 - office 903.224.5701 - mobile/GV ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optional delta argument for assertAlmostEqual
A good summary on floating point comparison algorithms can be found at http://www.boost.org/doc/libs/1_34_0/libs/test/doc/components/test_tools/floating_point_comparison.html I, too, redefine almostEquals so that the comparison is more robust +1 On Sun, Mar 28, 2010 at 2:06 AM, Steven D'Aprano wrote: > On Sun, 28 Mar 2010 02:54:19 pm Charles McCreary wrote: > > Perhaps not just absolute but relative tolerance, e.g.: > > > > def isclose(x, y, rtol=1.e-5, atol=1.e-8): > > return abs(x-y) <= atol + rtol * abs(y) > > I'm not sure why you add the tolerances like that. Surely a more > appropriate approach is to compare the values against the tolerances > individually, and return True if they meet either condition. > > For what it's worth, here's a recipe I wrote for approximately equal, > following someone's complaint on comp.lang.python that Python has no > approximately-equal operator. > > http://code.activestate.com/recipes/577124-approximately-equal/ > > Comments and criticism welcome. > > I've never found unittest.TestCase.assertAlmostEqual to be useful. I > generally write my own comparison function, then call: > > assert_(compare(x, y)) > > as needed. I'm +0.5 on Michael's suggested change -- it will make > assertAlmostEqual marginally more useful, which is a plus, but I'm not > sure that absolute tolerances are better than relative. But how general > do we want to be? "Almost equal" means something different to everyone. > > > > > On Fri, Mar 26, 2010 at 7:59 PM, Michael Foord > wrote: > > > Hello all, > > > > > > A user has suggested an optional argument to > > > unittest.TestCase.assertAlmostEqual for specifying a maximum > > > difference between the expected and actual values, instead of using > > > rounding. > [snip] > > > > -- > Steven D'Aprano > _______ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/charles.r.mccreary%40gmail.com > -- Charles McCreary P.E. CRM Engineering 903.643.3490 - office 903.224.5701 - mobile/GV ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
