Fix circular import with validate_call by sydney-runkle · Pull Request #10807 · pydantic/pydantic (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation7 Commits3 Checks54 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

sydney-runkle

@sydney-runkle

@cloudflare-workers-and-pages Cloudflare Workers and Pages

Deploying pydantic-docs with Cloudflare Pages Cloudflare Pages

View logs

@codspeed-hq CodSpeed HQ

@github-actions GitHub Actions

@Viicos

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).

@Viicos

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

@pytest.mark.filterwarnings('ignore::DeprecationWarning')
def test_init_export():
for name in dir(pydantic):
getattr(pydantic, name)

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

@sydney-runkle

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...

@sydney-runkle

@sydney-runkle

@Viicos

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

Viicos

2 participants

@sydney-runkle @Viicos