rator function in unittest.
Here is where the recipe is, for those who want to comment further:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288
--Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
Fredrik Lundh wrote:
> Scott David Daniels wrote:
>> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288
>
> my main nit is the name: the test isn't broken in itself, and doesn't need
> to be fixed; it's just not expected to succeed at this time
Fred L. Drake, Jr. wrote:
> Scott David Daniels wrote:
> > Would "expect_fail", "expect_failure", "expected_fail", or
> > "expected_failure", work for you?
>
> None of these use the same naming convention as the other unittest
erting to base-64 and other weird formats, as
well as providing decimal conversion into some unicode number ranges
outside the ASCII group.
--Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
ext
>lib_dir = "/lib"
>libs = glob.glob(os.path.join(lib_dir, "*s.o"))
>==>
>lib_dir = Path("/lib")
>libs = lib_dir.files("*.so")
Probably that should be:
...
libs = glob.g
ative_tolerance.
As to the equation itself, wouldn't a symmetric version be somewhat
better?
def nearby(x, y, rel_tol=1.e-5, abs_tol=1.e-8):
return abs(x - y) < abs_tol + rel_tol * (abs(x) + abs(y))
This avoids areclose(0, 1e-8) != areclose(1e-8, 0), for example.
--Scott David
difference <= max(abs(x), abs(y)) * relative_tol)
I use <=, since "zero-tolerance" should pass equal values.
--Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
101 - 107 of 107 matches
Mail list logo
