Chris Barker added the comment:
Yes -- it was on me years ago to do this.
Honestly, I haven't done it yet because I lost the momentum of PyCon, and I
don't personally use unittest at all anyway.
But I still think it's a good idea, and I'd like to keep it open with the
understanding
Chris Barker added the comment:
This does not actually appear to be a Duplicate of #33129.
That one was asking to add **kwargs (I think) to the __init__. And was
discussed and I think rejected on gitHub:
https://github.com/python/cpython/pull/19206
But this calls for having keyword-only
Chris Barker added the comment:
Yes Please!
I'd offer to help, but I really don't get the intricacies involved. I will
offer to proofread and copy-edit though, if that's helpful.
And I note that coincidentally, just in the last week, I needed to make an
absolute path from a Path
Chris Barker added the comment:
Agreed:
the custom dict type would be nice for a recipe or blog post or...
but not for the docs.
I'll note that the other trick to this recipe is that you need to know to use
lambda to make a "None factory" for defaultdict -- though maybe tha
Chris Barker added the comment:
Thanks Robert.
I'll try to find time to re-do the patch soon.
There was enough resistance to the whole idea that I wanted some confirmation
that is was worth my time to do that!
Stay tuned.
--
___
Python tracker
Chris Barker added the comment:
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 fin
Chris Barker added the comment:
Thanks Raymond.
Damn! I wrote a nice comprehensive note, and my browser lost it somehow :-(.
Here's a shorter version:
"FWIW, I find assertClose easy to misinterpret. At first, it looks like an
assertion that a file is closed."
sure -- we can find
Chris Barker added the comment:
"""w.r.t. error messages, a regular function that raises AssertionError with a
nice message will be precisely as usable."""
sure -- I totally agree -- but that's not the current unittest API :-( where
would you put it? How would
Chris Barker added the comment:
Would that make folks more amenable to adding more "specialized" asserts? If
so, then sure.
I don't know that it takes a PEP (I hope not) but it would be good to have some
guidance as to the direction we want unittest to take written down
Chris Barker added the comment:
Why a mixin rather than adding to TestCase? If they are useful they should be
easy to find.
Also, see Issue27198 for another possible new assert.
--
nosy: +ChrisBarker
___
Python tracker <rep...@bugs.python.
Chris Barker added the comment:
thanks, that's Issue27152 if anyone's curious.
Though I have no idea why you'd want it in a mixin, rather than just there.
But sure, this could be "bundled" in with that.
Perhaps it's time for a broader discussion / consensus about the future of the
Chris Barker added the comment:
I'm not sure it's confusing --what would "close" mean for an assertion for a
file? "assertClosed" would be confusing -- and an even more trivial assert :-).
But we can bikeshed the name if we decide to put this in.
"""
I certa
Chris Barker added the comment:
updated patch with the equation in the docs.
--
Added file: http://bugs.python.org/file43165/assertClose.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Chris Barker added the comment:
Thanks,
I'll add the equation to the docstring and docs.
As for adding a rel_tol to assertAlmostEqual -- I think that's a bad idea --
it's a pretty different concept -- overloading the same method would be more
confusing than anything else.
in isclose
New submission from Chris Barker:
In py3.5, the math.isclose() function was added to the standard library. It can
be used to compare floating point numbers to see if they are close to each
other, rather than exactly equal. It's not a lot of code, but there are nuances
that not every python
15 matches
Mail list logo
