fix int_validator not catching overflows

[ojii]

Change Summary

int(value) can raise an OverflowError, for example when called with very large floats.

Related issue number

#2345

Checklist

• Unit tests for the changes exist
• Tests pass on CI and coverage remains at 100%
• Documentation reflects the changes where applicable
• changes/<pull request or issue id>-<github username>.md file added describing change
  (see changes/README.md for details)
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

[ojii]

please review

[PrettyWood]

I reckon it would be better to catch the OverflowError in a separate except clause with a more explicit error. We could probably do the exact same for float

[ojii]

I reckon it would be better to catch the OverflowError in a separate except clause with a more explicit error.

Sorry, first time contributing to pydantic. Does that mean just changing the msg or the type of the error? If the latter, is there a way type codes are chosen?

[dimaqq]

Suggested change

	except (TypeError, ValueError, OverflowError):
	raise errors.IntegerError()
	except (TypeError, ValueError):
	raise errors.IntegerError()
	except OverflowError:
	raise errors.IntegerOverflowError()

I think this is meant.

[dimaqq]

Then, like 144

-        return float(v)
+        rv = float(v)
+        if rv in (float("inf"), float("-inf")):
+            raise errors.FloatOverflowError()
+        if rv != rv:
+            raise errors.FloatNanError()
+        return rv

P.S. the weird line of code from https://stackoverflow.com/a/44154660/705086

[samuelcolvin]

floats are a separate case. I would say that float('inf') is a valid float, arguably so is float('nan').

[samuelcolvin]

This is looking good, just a few things to fix and more test cases to add.

[samuelcolvin]

floats are a separate case. I would say that float('inf') is a valid float, arguably so is float('nan').

[samuelcolvin]

can you add the case of passing float('inf') etc.

[samuelcolvin]

please update.

[ojii]

This is looking good, just a few things to fix and more test cases to add.

@samuelcolvin i've added more test cases, do you think the error code/msg should be handled different? If so, how are new messages/codes decided?

[samuelcolvin]

At this stage, best if you can roughly follow the code from pydantic-core to minimize the incompatibility with v2.

[samuelcolvin]

https://github.com/samuelcolvin/pydantic-core/blob/fdf42b8b0d0684bc2cac04d34c40fe4b0d33498d/tests/validators/test_int.py#L207

[ojii]

Since the structure of the error dict is different between v1 and v2 anyway, does it make sense trying to make it v2-like? I feel making it fit in with the rest of v1 makes more sense (eg in v1, error codes seem to always be prefixed with type_error. or value_error. but in v2 not?)

[samuelcolvin]

Yes, that's what I meant by roughly follow, e.g. use value_error.int_nan?

[ojii]

Yes, that's what I meant by roughly follow, e.g. use value_error.int_nan?

When I change it to that, interestingly enough float('nan') gets caught in the already existing exceptions (ValueError). This proposed change (catching OverflowError) only catches float('inf') or other huge floats, so int_nan is probably not the right thing here.

[samuelcolvin]

Okay, let's just stick with this then.

[samuelcolvin]

Good catch, thanks so much for the PR.