You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The schema handling logic and struct objects aren't MessagePack specific, and could be adopted for other protocols. This would allow an application to switch between JSON and MessagePack, while making use of the same schemas and objects throughout. I don't plan on working on this anytime soon, but adding support for JSON here isn't unreasonable. Unlike MessagePack though, parsing JSON is nontrivial, so adding support would require some care.
I no longer think this makes sense (at least for now). With the addition of extension types (and encoder hooks), there is enough msgpack specific things in here that anything json-specific would likely best be handled in a separate repo.
It could be nice to have something like Pydantic but where the model and validation definition are completely separate from the serialization protocol so that the serialization can be a pluggable piece.
Activity
jcrist commentedon Jun 28, 2021
I no longer think this makes sense (at least for now). With the addition of extension types (and encoder hooks), there is enough msgpack specific things in here that anything json-specific would likely best be handled in a separate repo.
jcrist commentedon Jul 7, 2021
Actually, I am going to reopen this. Except for
msgspec.Ext, everything here still applies to json.adriangb commentedon Aug 10, 2021
It could be nice to have something like Pydantic but where the model and validation definition are completely separate from the serialization protocol so that the serialization can be a pluggable piece.
Fix `Meta(pattern=..)` memory leak / corruption (msgspec#1256)