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

Support adding hooks for supported objects types #671

Open
mike0sv opened this issue Apr 19, 2024 · 2 comments
Open

Support adding hooks for supported objects types #671

mike0sv opened this issue Apr 19, 2024 · 2 comments

Comments

@mike0sv
Copy link

mike0sv commented Apr 19, 2024

Description

Right now, dec_hooks and enc_hooks are called only if msgspec encounters unknown type. I'd like a way to override dec/enc logic for specific supported types, but there is no way to do it rn. Possible solutions:

  1. add new argument with Dict[Type[T], Callable[[T], Any] that works even if T is subclass of Struct or any other supported type
  2. inspect argument type annotation for callables passed to dec_hooks and enc_hooks. If it is annotated with some type, use hook even if type supported natively
  3. introduce special (possibly dunder method) that can override default enc/dec logic. It can look something like this in python: decoded = if hasattr(obj.__class__, "__decode__") obj.__decode__(obj) else <native logic>. This will only work for Struct subclasses though
@mike0sv mike0sv changed the title Support adding hooks for supported objects Support adding hooks for supported objects types Apr 19, 2024
@wikiped
Copy link

wikiped commented Apr 24, 2024

Linked: #669

@kevin-lee-dialpad
Copy link

we have the same problem.
msgspec json encoder supports a lot more types by default which sometimes isn't what we want(ex. sometimes we'd rather have serialization to fail rather than letting it pass and create an encoded data that we wouldn't know what type to decode it to by the time it gets to deserialization step).
and sometimes the way that msgspec json serializes certain supported types just isn't what we want.

both of these issues can be dealt with if there's a way to override behaviour for certain supported types.

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

3 participants