New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supports...
Protocol strategies bugs & suggested improvements.
#2292
Comments
also most of these protocols are direct mappings in the I'd be happy to open a PR for the changes if maintainers don't see any problems with these suggestions. |
Ooh, thanks for looking into this! Short on time now, but I'll share more thoughts tomorrow about what would be helpful in a PR |
|
cool i will have a go at it then!
yeah this makes sense and i don't suppose it's much work for users to filter downstream if this is what they're after... It's just me being lazy and (and possibly wanting SupportOps to be way more powerful than they are/should be).
yeah i was looking at the regex for floats but really that requires lookaheads to do properly and is more complex. int should be simpler... something like :
and we could avoid filter altogether.
As to collection stuff I will make another issue so we can discuss if that's cool... for SupportsOp stuff it's pretty much just numeric so we shouldn't be an problem. |
thinking about it another option might be to make a general longterm could extend to stuff like error filtering (ie for overflow error) at users discretion.... |
|
fair nuff I may have gotten a bit carried away! I'll do a pr patching to patch the updates into |
complex numbers do not have a __round__ method. see HypothesisWorks#2292 for more details
* test for support ops types note that this does not currently work in python < 3.8 before changes to make these `typing.Protocol` types. which is a bummer... will have to work out a solution. * add workaround in test for python < 3.8 * fix strategy for SupportsRound complex numbers do not have a __round__ method. see #2292 for more details * update SupportsBytes * add special test for supports bytes * SupportsBytes is a subclass of Hashable... so we do the tuple thing again... * update tests for support ops - add a couple helper functions - split tests into those for which only an interface is expected and those for which in the absence of an interface we may try and cast a value * add bytes back into SupportsBytes strat * add SupportsInt basic strat * remove nan and inf constraints. * update SupportsRound strategy and pep8 * add comment to the int string thing * add SupportsFloat strategy * loosen error type in cast just in case * pep8 * update SupportsComplex strategy * add testcase for SupportsComplex test * add RELEASE.rst * reformat stuff using reformat script * test that the value generated by the strategy is not a dummy instance of the protocol itself * fix name error causing all sorts of chaos * silence flake8 on bytes for SupportsBytes test case * fix lint err * pep8 again * pep8 * use one_of * change to minor version * fix link refs in RELEASE.rst * correct regex for SupportsInt strings * remove usless comment in supports_casting * inline assertion and fix comment * simplify supports_protocol * change wording in release notes * SupportOps strategies to multiarg form of one_of * black formatting * Fix build for Pandas 0.19 * Minor refactor Co-authored-by: Zac Hatfield-Dodds <Zac-HD@users.noreply.github.com>
Closed by #2297 |
Supports...
Protocol strategies bugs & suggested improvements.hypothesis: 4.56.1
python : 3.7.4
The following are suggested improvements for the
typing.Supports...
protocol types. The general expectation is that if i dofrom_type
on a one of these protocol types i will get at minimum all strategies which generate values who's types support the protocol. At the moment many of them are looking pretty bare and so wouldn't be generating the range of values a user would expect.For each protocol below I've provided the underlying current strategy drawn by
from_type
and a suggested strategy.I gathered the suggested strategies with a little help from
hypothesis.find
and have also tried to optimize the order of the statigies with a little stupid heruristic funtion to support good shrinking. I then did some basic tests with the example function to make sure they hold.There are also a couple which contain bugs. I will try and clarify where that is the case in each example:
typing.SupportsInt
current strategy:
floats()
example:
BUGS: The above currently fails it's not protected from infinites and nans.
suggested strategy:
really really nice to have:
another nice touch would be to add a stringified version of int particularly since casting from string is such a common use case
typing.SupportsAbs
current strategy:
complex_numbers()
example:
BUGS:
we encounter an overflow error on on an huge complex number
suggested strategy:
we need to limit the mangitude on complex numbers to avoid overflow. The threshold below is just a guess...
nice to have:
support for
numpy.extra
where applicable since most numeric arrays supportabs
.typing.SupportsRound
current strategy:
complex_numbers()
example:
BUGS:
We quickly get a
TypeError
since complex numbers don't define__round__
method !!!suggested strategy:
typing.SupportsFloat
current strategy:
floats()
example:
The current strategy doesn't have any overt bugs it's just too permissive.
suggested strategy:
really really nice to have:
as with
SupportsInt
would be really nice to include stringified floats in the strategy since it's a common use case.I haven't covered
SupportsBytes
andSupportsComplex
( sorry i got a bit knackered of writing..) but they also look too narrow. So maybe worth having a look into them as well.I'll file another issue for improvements to abc type protocols when in a bit. If this format is overwhelming let me know and i'll do issue per strategy instead of grouping together.
The text was updated successfully, but these errors were encountered: