Deploying pydantic-docs with    Cloudflare Pages

View logs

CodSpeed Performance Report

Merging #10807 will not alter performance

_{Comparing fix-circular-ref (21f5813) with main (421c2fb)}

Summary

✅ 44 untouched benchmarks

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
pydantic
validate_call_decorator.py
pydantic/_internal
_generate_schema.py
_validate_call.py
Project Total

This report was generated by python-coverage-comment-action

It should be the other way around I think, the _generate_schema module should import VALIDATE_CALL_SUPPORTED_TYPES and ValidateCallSupportedTypes in an if TYPE_CHECKING: block/ inside the match_type call. More generally, this circular import is a sign that things are not properly isolated. I think it would make sense to define VALIDATE_CALL_SUPPORTED_TYPES and ValidateCallSupportedTypes in the _generate_schema module, and let _validate_call import from there. After all, a _call_schema isn't only limited to @validate_call, you can very much do TypeAdapter(some_callable).

Additionally, there's the test_init_export that was supposed to catch these issues

but it probably requires cleaning sys.modules before each getattr call, and I couldn't make it work

Additionally, there's the test_init_export that was supposed to catch these issues

I don't think this matters, as we're using two _internal files, so it's not supposed to catch them there...

Additionally, there's the test_init_export that was supposed to catch these issues

I don't think this matters, as we're using two _internal files, so it's not supposed to catch them there...

The idea is that we should have a test making sure that every from pydantic import x top level import works. This one does but because pydantic is already imported in various places (in different test files during pytest test collection, etc), it did not catch the circular import, and I find it a bit concerning as this could happen at any time