checkcast: Provide information as to why a type is not "assignable"

[phlax]

Ive been using trycast for a while for runtime type checking (mostly yaml/json -> TypedDict) and its working great (thanks)

Mostly i use a pattern of checking if something is assignable and raising a TypeCastingError with the failing value to allow handling further up the stack

What would be really helpful is to be able to expose why the object is not assignable (eg "incorrect key", "incorrect type for key", "missing key" etc)

i guess there is some complexity around issues with different types of Type

implementing this might also add some complexity around continuing after the first failure and collecting the errors etc

[davidfstr]

Right now trycast() returns:

• (A) [original value if successful] | [None if failure]

In order to return additional information about the failure, it would need to return instead something like:

• (B) [original value if successful] | [exception with details if failure]

---

I have been thinking about adding a new checkcast() function to the API that would effectively return (B).

With a checkcast() function available, you could replace code like:

if (movie := trycast(Movie, request_json)) is not None:
    ...  # expects a movie
else:
    raise ValueError("Expected a Movie") 

with shorter code like:

movie = checkcast(Movie, request_json)
...  # expects a movie

If there was a type-checking error, checkcast() would raise a custom subclass of ValueError. Information about the type-checking failure could be provided in the message of that exception.

---

Do you think a new API like checkcast() (as described above) would help with your issue here?

[phlax]

Do you think a new API like checkcast() (as described above) would help with your issue here?

yep definitely, the main thing i want to be able to do is raise a message to the end user giving a hint on how to fix, so i think that would work

the slightly more complex solution would be rather than raising a single error on a match-fail, collecting the errors and providing a fuller analysis, but i think that adds quite a bit of complexity and just having an error which indicates the first failure would be great

[davidfstr]

raise a message to the end user giving a hint on how to fix, so i think that would work

For your own use case, is this a developer end user (who is directly using trycast() or checkcast()) or an upstream non-developer end user?

The reason I ask is that a string-based error message would probably be sufficient for a developer end user but a structured/JSON error message (like the ones that pydantic generates in its ValidationErrors) would likely be necessary for an upstream non-developer end user, since the error message would need to be readapted by upstream code to a customized end-user-facing message.

(I might just generate both types of error messages anyway, but if I generate the latter kind then I need to provide some kind of format/API guarantee, which is more expensive.)

[phlax]

so my direct use case is in CI - so it is developers, but not developers of the python app (for ref Envoy CI https://github.com/envoyproxy/envoy)

eg it might open a extensions.yaml file to parse extensions metadata

what im doing now is depending on the type of fail either raising/handling immediately, or logging a warning and hoping for the best

currently the log/error dumps the parsed contents of the file which is a python dict so not that helpful

it would be good to give an indication to the end users (who happen to be devs) - "the format of the yaml file you edited is wrong - try fixing this"

as this is kinda specific to the format being consumed and its schema, i was expecting/hoping to catch some type of error/info and dump a message based on that, but exposing any info as to what was wrong would be better than just dumping the data as i do now

[davidfstr]

Thanks for taking the time to explain your scenario. I've got a much better understanding of what you're trying to do.

For now I'll file this issue as a post-1.0 feature request.

[kraktus]

just a user report, to say I'd have been interested in this feature as well. Thanks for the lib.

[davidfstr]

checkcast will be released in v1.2.0

[phlax]

nice, thanks!

[davidfstr]

trycast v1.2.0 (and checkcast) have been released 🥳