Deploying pydantic-docs with    Cloudflare Pages

View logs

CodSpeed Performance Report

Merging#10807 willnot alter performance

_{Comparingfix-circular-ref (21f5813) withmain (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 bypython-coverage-comment-action

It should be the other way around I think, the_generate_schema module should importVALIDATE_CALL_SUPPORTED_TYPES andValidateCallSupportedTypes in anif TYPE_CHECKING: block/ inside thematch_type call. More generally, this circular import is a sign that things are not properly isolated. I think it would make sense to defineVALIDATE_CALL_SUPPORTED_TYPES andValidateCallSupportedTypes 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 doTypeAdapter(some_callable).

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

but it probably requires cleaningsys.modules before eachgetattr 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 everyfrom pydantic import x top level import works. This one does but becausepydantic 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