These both seem like reasonable feature requests, and I believe they'll require some work in pydantic-core! PRs welcome :).

Hi, I'd like to contribute on this issue (as my first contribution). Still trying to understand the whole architecture of the pydantic project.
Is there some documentation or examples I could follow to create a new validator?

@yfalomir,

Awesome! Hmm, yeah we'll have to decide on exactly what we want the API to look like regarding the rounding behavior.

Before we do that, @Zac-HD, do you think there's any place for some sort of rounding annotation in annotated-types? If not, we can implement a solution purely in pydantic, but wanted to get your feedback first :).

Let's start with just Pydantic, and then we can move it to annotated-types if there's wider demand for it and consensus on the semantics 🙂

It would be very difficult for e.g. pschanely/CrossHair#201 to support float rounding.

How do you want to proceed about deciding what the API should look like?

Maybe I can make propositions if you point me to relevant chunks of codes to compare the issue with.

@yfalomir,

Ah, apologies for the delay, this notification got buried in my email. Why don't we start with an implementation that uses Python's round function (for simplicity, and also then the rounding behavior isn't dependent upon custom logic). What do you think about round_to as the setting name (takes an int)? I wouldn't worry too much about adding support for this to types like confloat for now...

I think the decimal_places support for floats is going to be more difficult, due to differing internal storage mechanisms on different machines.

Sorry for the delay, I will make a proposition this week.

Sorry I'm a bit late to the party, but regarding round_to this creates a precedent, as from what I can see all the Field arguments currently are validation constraints, but they don't alter the provided values.

I imagine for 2 it would look like:

from pydantic import Field, BaseModel


class MyModel(BaseModel):

    my_field: float = Field(round_places=2)

my_field: float = Field(round_places=2) vs my_field: Annotated[float, AfterValidator(round_float(2))] isn't too much of a difference imo, and the later could even be simplified with:

from pydantic import AfterValidator

def round_to(ndigits: int, /) -> AfterValidator:
    return AfterValidator(lambda v: round(v, ndigits))

class Model(BaseModel):
    my_field: Annotated[float, round_to(2)]

What I'm mostly worried about is if this is added to the Field function, we'll probably see more similar feature requests (e.g. a Field option to round the float to the highest integer, then the lowest, etc) that will be hard to decline

I don't feel like I can give on informed opinion on the matter. @sydney-runkle maybe you could help me on this?

@yfalomir,

Yes, certainly! I'll review your PR and the above comments today!

@yfalomir,

Honestly, I agree with @Viicos. It'd be great to not set that precedent.

Closing this for now, as I think the above suggested approach is generally quite clean, and exactly how we expect annotated types to bring great value. Thanks for the feedback and effort, folks!