Numerically constrainted fields don't generate proper error on non-Number fields

[AnthonyVH]

It's possible to create for example a GreaterThan constraint on a field which is not number, but still has the required comparison operators. This works fine, except that when the constraint is violated, a TypeError exception is thrown during the generation of the PydanticKnownError.

The cause of this is the call to field_from_context when the constraint isn't met. This requires the object to compare against to be a Number (well, for GreaterThan it does). When that isn't the case, it triggers line 56 in src/errors/types.rs, causing the TypeError.

I'm running into this for a model I've made that validates astropy.units.Quantity fields. In this case, the object to constrain against could be for example 5 * astropy.units.meter.

It's not clear to me why pydantic-core requires this object to be a Number. It seems that it having the required comparison operator (to do the check) and being able to be converted into a string (to generate an exception message) should be enough. Both are the case for a astropy.units.Quantity object.

Edit: I can't trigger this when the annotated field is a string (Annonated[str, Field(gt="b")]) so maybe I'm misunderstanding the exact reason the TypeError is raised.

[davidhewitt]

You're absolutely correct in identifying Number as the root cause and IMO that's an unnecessary constraint (especially as this is an error message). Probably the whole Number enum can be removed and we should just use PyObject there to allow any Python object. A PR to relax this would be welcome 👍

[AnthonyVH]

I've had a look at the code, but I'm afraid my Rust is not up to snuff to put together a proper PR 😅.

[mikeedjones]

I can only reproduce this with

class CustomComarable:
    value: int

    def __init__(self, value):
        self.value = value

    def __gt__(self, other):
        raise TypeError("CustomComarable does not support comparison")

v = TypeAdapter(Annotated[CustomComarable, Field(gt="2")], config={"arbitrary_types_allowed": True})

v.validate_python(CustomComarable(1))

I think what @AnthonyVH is seeing is a type error being raised by astropy.units.Quantity.__gt__ raised when the comparison is made on l268

# pydantic/_internal/_validators.py:272

def greater_than_validator(x: Any, gt: Any) -> Any:
    try:
        if not (x > gt):
            raise PydanticKnownError('greater_than', {'gt': _safe_repr(gt)})
        return x
    except TypeError:
        raise TypeError(f"Unable to apply constraint 'gt' to supplied value {x}")

It kinda makes sense that astropy.units.Quantity.__gt__ is raising a type error because 5*astropy.units.meter is not serializable so can't be passed asgt:

TypeAdapter(Annotated[str, Field(gt=5*astropy.units.meter)])

# PydanticSerializationError: Unable to serialize unknown type: <class 'astropy.units.quantity.Quantity'>`

so I think @AnthonyVH's model might be using something like Field(gt="5m") which causes the type error in astropy.units.Quantity.__gt__?

All that said I think

diff --git a/src/errors/types.rs b/src/errors/types.rs
index 0c75e1e2..1206a5b2 100644
--- a/src/errors/types.rs
+++ b/src/errors/types.rs
@@ -201,19 +201,19 @@ error_types! {
     // ---------------------
     // generic comparison errors
     GreaterThan {
-        gt: {ctx_type: Number, ctx_fn: field_from_context},
+        gt: {ctx_type: PyObject, ctx_fn: field_from_context},
     },
     GreaterThanEqual {
-        ge: {ctx_type: Number, ctx_fn: field_from_context},
+        ge: {ctx_type: PyObject, ctx_fn: field_from_context},
     },
     LessThan {
-        lt: {ctx_type: Number, ctx_fn: field_from_context},
+        lt: {ctx_type: PyObject, ctx_fn: field_from_context},
     },
     LessThanEqual {
-        le: {ctx_type: Number, ctx_fn: field_from_context},
+        le: {ctx_type: PyObject, ctx_fn: field_from_context},
     },
     MultipleOf {
-        multiple_of: {ctx_type: Number, ctx_fn: field_from_context},
+        multiple_of: {ctx_type: PyObject, ctx_fn: field_from_context},
     },
     FiniteNumber {},
     // ---------------------

Would address the idea from @davidhewitt? But I can't figure out a test case for it :(

I guess there's the question of whether the schema should allow you to supply constraints which are not valid for a given type? I think it would be very difficult to implement and expensive to check when generating schema.