Skip to content
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 and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Annotated in is_subtype (transparently ignoring the annotations) #19

Closed
apirogov opened this issue Dec 16, 2022 · 6 comments

Comments

@apirogov
Copy link

In my project I am using pydantic and use its Field(...) configuration e.g. to define alias names for keys within Annotated, e.g.

x: Annotated[int, Field(alias="y")]

but I need to check is_subtype on the wrapped types (I don't use the annotation for any type-domain related info).

It would be great if Annotated could be transparently ignored.

I understand there are many "semantics" one could give to checking Annotated types, but as the annotation is quite arbitrary and tool specific, I think that simply ignoring the annotation and recursing down the actual type would be the "right" default behavior.

A more conservative solution I would also be happy with would be to have this as some keyword argument to is_subtype, called e.g. ignore_annotations to have that behavior and do with them whatever you believe would make more sense as the default.

But in my case, the annotation object (pydantic.FieldInfo) does not have even equality, so this would not work for me to check that the annotations must all be equal or something like that. Thats why I think it does not make any sense to try doing anything with the annotations but ignoring them, as it probably would not work in the general case.

@erezsh
Copy link
Owner

erezsh commented Dec 16, 2022

Is the Annotated object always top-level? Because if so, it should be easy to write a function remove_annotations, that simply unwraps them before calling is_subtype.

@apirogov
Copy link
Author

apirogov commented Dec 16, 2022

That is currently what I am doing, and it's working fine - for now :) But I'd rather remove the workaround if possible.

I don't think there is any restriction prohibiting Annotated nesting (also why should there be? you might attach e.g. analysis information / any kind of metadata on various levels of composed types).

I just thought it would be a neat thing to have a clean solution instead of such a use-case specific "hack" (and I am not sure whether this will be sufficient on the long term, if more and more Python libraries adopt typehint-based stuff and place their magic into the annotations). And After all, Annotated is a standard hint included in typing in the recent Python versions.

@erezsh
Copy link
Owner

erezsh commented Dec 16, 2022

Sorry, I misunderstood, I thought you're talking about a feature that's specific to pydantic.

Yeah, I agree, runtype should cover everything that's in typing. I'll see if I can find time for it soon.

erezsh added a commit that referenced this issue Dec 17, 2022
Add support for typing.Annotated (Issue #19)
@erezsh
Copy link
Owner

erezsh commented Dec 17, 2022

@apirogov Should be now fixed in master.

@apirogov
Copy link
Author

apirogov commented Dec 18, 2022

In Python 3.8 Annotated is in typing_extensions and it does not seem to work:

is_subtype(List[int], Annotated[List[Annotated[int, "hello"]], "world"])) yields

NotImplementedError: ('No support for type:', typing_extensions.Annotated[typing.List[typing_extensions.Annotated[int, 'hello']], 'world'])

(expected: types are equivalent, i.e. True in both directions)

@erezsh
Copy link
Owner

erezsh commented Dec 29, 2022

I think I fixed it!

@erezsh erezsh closed this as completed Apr 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants