This seems pretty niche to me, so I'm afraid this will introduce attractive nuisances if implemented as is.

Could you expand on why you don't need validation to performed on instantiation? The goal of Pydantic is to make sure data is validated so that you can safely make use of it.

You could also go a different way we a solution that might suit your use case better:

hashes is fully determined from files. This seems to be a great fit for defining it as a @property/@cached_property (with an invalidation mechanism to be implemented). You could also define files as a list[File], File being a separate model. This will scale better (you'll be limited with your current approach whenever you need to add extra info to the files), and you can define a hash cached property on File (no need to implement any invalidation mechanism this time), and have hashes defined as a simple property returning [f.hash for f in self.files].

I don't have any estimates on how niche it is, but my initial guess would be somewhere around how niche properties with setters are? Am not sure why this would be an attractive nuisance. Since this would directly address these issues:
#6597
#6429 (comment)
#8185
#8474
Among others where the behavior of validation on assignment is not very intuitive, it doesn't seem that niche to me, but you know better than i do I suppose.

You could also go a different way we a solution that might suit your use case better:

Those are possible options if I was not trying to model an existing format and the format was arbitrary. Part of the benefit of having the pydantic model being a direct reflection of the format is that serialization/deserialization is direct: I just dump the model and bencode it: this is directly in line with the spirit of making sure the data is validated so you can use it, just that validity is nonlocal and depends on the alignment of multiple fields.

Hashing can take quite a long time and is stored in the torrent file when read, so cached property is not really a great fit. Plus would still need a trigger to invalidate it from another field changing, which circles back to this issue

you'll be limited with your current approach whenever you need to add extra info to the files

I'm not sure how? Since the hash only depends on the files, any other fields won't affect this feature or the hash calculation.

I'm not sure the issues you linked are showing exactly the same problem; for instance in #6597, I assume the author also want validation to run on instantiation.

Hashing can take quite a long time and is stored in the torrent file when read, so cached property is not really a great fit.

But cached property is precisely meant for this right? Only computed once, and a proper invalidation mechanism makes it so that it is only recomputed when needed. More broadly I think properties still are a better fit for your use case. For instance, what if someone does torrent.files.append(Path(...))? Then your hashes are inconsistent but there is no way to catch this with validator on assignments.

I'm not sure how? Since the hash only depends on the files, any other fields won't affect this feature or the hash calculation.

What I meant is that currently a file is represented as a pathlib.Path. If you ever need to expose some useful properties in the future, it wont be possible unless you do something like:

class TorrentFile(BaseModel):
    path: Path
    some_useful_attribute: <...>

    @property
    def hash(self):
        ...

class Torrent(BaseModel):
    files: list[TorrentFile]

Related Issues

Fair, not obvious how some of those issues are related, so here's a little more detailed breakdown of some prior issues that I think having this would help resolve.

class User(BaseModel):  
    model_config = ConfigDict(validate_assignment = True)

    name: str
    other : Optional[str] = None
    
    @model_validator(mode = 'after')
    def validate_me(self):
        self.other = 'abc'
        return self

def _set_other(self, value: Any, info: ValidationInfo) -> Self:
    self.other = "abc"
    return self

SetOther = Annotated[T, AfterAssignmentValidator(_set_other)]

class User(BaseModel):
    name: SetOther[str]
    other: str | None = None

class User(BaseModel):  

    name: str
    other : Optional[str] = None
    
    # this, or assignment_only=True, or whatever the syntax may be
    @field_validator("name", mode = 'after', when_used="assignment")
    def set_other(self, value: Any):
        self.other = "abc"
        return self

class MyModel(BaseModel):
    model_config = ConfigDict(validate_assignment=True)

    n_assignments: int = -1  # ideally this should be 0, but can't do assignment-only validators
    event_threshold: int = 10
    event: Callable 
    value: str = "something we assign to a lot"

    @model_validator(mode="after")
    def increment(self) -> Self:
        self.n_assignments += 1
    
    @field_validator("n_assignments", mode="after")
    def emit_event(self, value: int, info: ValidationInfo) -> Self:
        if value > info.data['event_threshold']:
            info.data['event']()
            return 0
        return value

from pydantic import BaseModel, computed_field

class Circle(BaseModel):
    radius: int
    unrelated_prop: str

    @cached_property
    def diameter(self) -> int:
        return self.radius * 2

    @field_validator("radius", mode="after", assignment_only=True)
    def invalidate_diameter(self):
        del self.diameter

distinction from @property and @cached_property

But cached property is precisely meant for this right? Only computed once, and a proper invalidation mechanism makes it so that it is only recomputed when needed.

Right, so another way of asking for what i'm asking for is a way of writing that invalidation mechanism - a way of having assign-time side effects on the model that don't recurse.

• @property: either cannot be passed a value on instantiation, needs a private attr or a differently-named attr to store value. @property is not responsive to the need here, as we want to trigger invalidation from mutating other fields. we also want this to be dumped when the model is dumped
• @cached_property - same as Make @computed_field (optionally) initializable #9131 , we also want to be able to init the model with these values if they are already precomputed, and then only recompute them if we need to.

The reason these don't really work is the same reason that @property has @property.setter - sometimes we want something to happen to other fields on the model, or use the values of other fields to do something when the value is changed.

Other problems

For instance, what if someone does torrent.files.append(Path(...))

It is true that this would not solve all problems, but it would solve the problem i am having.

What I meant is that currently a file is represented as a pathlib.Path. If you ever need to expose some useful properties in the future, it wont be possible unless you do something like:

I am not quite sure how this is relevant to the need for assignment-only validation behavior, but again just to clarify i am modeling an already-existing specification, so the fields are already prescribed and we can't really remodel our way around problems like this (if we want the model to be a 1:1 representation of the spec, which we do).

class FileItem(BaseModel):
    length: int
    path: list[FilePart]
    attr: L[b"p"] | None = None

class InfoDictV1(InfoDictRoot):
    pieces: Pieces | None = None
    length: Annotated[int, Gt(0)] | None = None
    files: Annotated[list[FileItem, MinLen(1)] | None = None
    piece_length: V1PieceLength = Field(alias="piece length")

Another alternative

if this is too complicated or sounds like a bad itea, i would settle for having the information about what initiated a validation call in the ValidationInfo object so i could roll my own assignment-only validator, like

class MyModel(BaseModel):
    something: int

    @field_validator("something", mode="after")
    def something_else(cls, value: int, info: ValidationInfo) -> int:
        if info.initiator.type == "assignment":
            # do something that's assignment-only
        return value
        

That seems like it would be generally good to have, as more information about the initiating context would have been useful in several other situations, but it would directly address my need here too.

again just to reiterate that i am not showing up here demanding y'all do work for me, if we arrive at something that sounds reasonable i am happy to draft it!

For instance, what if someone does torrent.files.append(Path(...))

It is true that this would not solve all problems, but it would solve the problem i am having.

What I meant is that currently a file is represented as a pathlib.Path. If you ever need to expose some useful properties in the future, it wont be possible unless you do something like:

I am not quite sure how this is relevant to the need for assignment-only validation behavior, but again just to clarify i am modeling an already-existing specification, so the fields are already prescribed and we can't really remodel our way around problems like this (if we want the model to be a 1:1 representation of the spec, which we do).

What I am trying to express here is that Pydantic can't reasonably introduce solutions that will perfectly fit every user use case. I understand you need to have a 1:1 representation of some spec that might not be ideal, but Pydantic can't be held responsible for this.

Instead of providing validators only for assignment, having a really limited scope, we need to find more generic ways on achieving such behavior.

For instance, you could have your model defined as:

from pydantic import BaseModel, SkipValidation

def update_hashes(instance, attribute, value):
    instance.files = value
    # Recompute hashes
    instance.hashes = ...

class Torrent(BaseModel):
    files: list[Path] = Field(on_setattr=update_hashes)
    hashes: SkipValidation[list[bytes]]

Inspired from attrs's on_setattr.

Your alternative in ValidationInfo seems also more reasonable to me.

What I am trying to express here is that Pydantic can't reasonably introduce solutions that will perfectly fit every user use case. I understand you need to have a 1:1 representation of some spec that might not be ideal, but Pydantic can't be held responsible for this.

Absolutely understood! Not trying to be ornery or saying "pydantic fix my special problem," only reason I raised the issue is because I think it is a more general need and would benefit other use cases, which is why I gathered the related issues and tried to describe how this would benefit them.

Inspired from attrs's on_setattr.

This is great! And would be exactly what I need. If I'm reading the docs right, what I pitched above is basically a pydantic flavor of on_setattr, with annotated and decorated validators instead of in the field.

Your alternative in ValidationInfo seems also more reasonable to me.

Also great! If this is preferable I can make a fuller sketch. I'll go through and find all the other kinds of contexts where a validator can be called so it's a more general solution than just detecting assignment, e.g. being able to differentiate between direct instantiation vs. Instantiation nested within a model would also probably be helpful. Will need a little bit of scoping input on that - don't want to make it just an edge case feature that is incomplete, but also don't want to blow it up into a huge change.

This is great! And would be exactly what I need. If I'm reading the docs right, what I pitched above is basically a pydantic flavor of on_setattr, with annotated and decorated validators instead of in the field.

Seems like it, and on_setattr has the benefit of fulfilling many other use cases not limited to validation.

I think we'll explore more on_setattr so I'll report here for any progress. We'll try to see if it can fit for 2.12.