Make ValidationInfo generic for context

[Viicos]

Change Summary

Fixes pydantic/pydantic#11485.

Example usage:

@dataclass
class MyContext:
    some_value: int

def validator(value: int, info: ValidationInfo[MyContext]):
    ...

One one hand, it isn't strictly correct to give the validator implementation a way to "enforce" (at least from a static type checking perspective) a context type, as ultimately this can be unsafe if provide a different context value in the validate functions. On the other hand, it is convenient if you are guaranteed that the correct context will be used during validation.

If users don't control how validation is performed, they can still leave ValidationInfo unparameterized (and have the context type fallback to Any | None) and have safety guards on the info.context value.

Related issue number

Checklist

• Unit tests for the changes exist
• Documentation reflects the changes where applicable
• Pydantic tests pass with this pydantic-core (except for expected changes)
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

[codspeed-hq]

CodSpeed Performance Report

Merging #1686 will not alter performance

_{Comparing validation-info-generic (3f378eb) with main (0a5bbfc)}

Summary

✅ 157 untouched benchmarks

[davidhewitt]

Do we need to call this out in the changelog?

[Viicos]

Pydantic already requires 4.12, so I don't think so.

[davidhewitt]

Should we add some mypy tests for this / maybe also the covariance?

[Viicos]

We can do so in Pydantic after updating the core version. The covariance is required because it is a Protocol, but I'm wondering if it really makes sense. At runtime, it is defined as a pyo3 class: shouldn't we move it's definition to the stub file instead?

[Viicos]

I guess maybe it is defined this way so that it cannot be instantiated (at least for static type checkers, at runtime it would still be possible)?

[davidhewitt]

You mean move this ValidationInfo definition to _pydantic_core.pyi? That seems probably correct to me?

EDIT see below

[davidhewitt]

Ah actually it's not exported by the library, so having it in _pydantic_core.pyi seems slightly incorrect, it's not actually importable from there at runtime.

I guess this is why it's defined as a protocol here, the Rust type then satisfies the protocol without needing to actually be related to it in the hierarchy.