Using TypeAdapter with PyRight has typing issues

[skewty]

Initial Checks

• I have searched Google & GitHub for similar requests and couldn't find anything
• I have read and followed the docs and still think this feature is missing

Description

Hoping something can be done with typing to make it get along better with PyRight. See below:

from pydantic import AnyHttpUrl, TypeAdapter

def ensure_url(url: AnyHttpUrl | str) -> AnyHttpUrl:
    if isinstance(url, str):
        return TypeAdapter(AnyHttpUrl).validate_python(url)  # pyright: ignore [reportCallIssue, reportReturnType]
    return url

Affected Components

• Compatibility between releases
• Data validation/parsing
• Data serialization - .model_dump() and .model_dump_json()
• JSON Schema
• Dataclasses
• Model Config
• Field Types - adding or changing a particular data type
• Function validation decorator
• Generic Models
• Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
• Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

[Viicos]

Duplicate of #7094

[sydney-runkle]

@Viicos,

Any suggestions for how we might fix this?

[skewty]

Additionally AnyHttpUrl (and I am expecting the other variants too) cannot be used with isinstance() which is counter intuitive.
Perhaps proper classes should be created and used? class Url(str) and all the various subclasses with different validation requirements.

[Viicos]

Any suggestions for how we might fix this?

#8923 will suppress the error, however the type variable of TypeAdapter will be inferred as TypeAdapter[Any].

To properly support this I'm afraid the only solution is to have type forms to land, but this is an active subject: python/mypy#9773.

Additionally AnyHttpUrl (and I am expecting the other variants too) cannot be used with isinstance() which is counter intuitive.

I agree this can be counter intuitive. Switching from Annotated constraints to proper subclasses probably requires a lot of work as well :/

[sydney-runkle]

Yeah, I think we do actually want to switch to proper subclasses: #7353. So I think that's probably the way forward here.

[sydney-runkle]

For now, let's have the subclasses replace the exiting types in pydantic, then we can move them to pydantic-extra-types when we do a V3 release.

[skewty]

For now, let's have the subclasses replace the exiting types in pydantic, then we can move them to pydantic-extra-types when we do a V3 release.

Great time to address this issue #9159.