Repository navigation
Attrs Support? #51
Description
Any consideration being given to supporting Attrs (https://www.attrs.org/en/stable/index.html) as a mechanism for Structs? It would be nice to leverage already existing attrs classes instead of refactoring to completely supporting the Structs. There is a workaround to just leveraging the attr.as_dict method to serialize into msgpack via encode; then deserialize into a from_dict classmethod; but that precludes taking advantage of the serialization/deserialization speedup documented for using structs over dicts.
Activity
jcrist commentedon Feb 8, 2022
I don't intend to add direct attrs support to msgspec, but attrs types could be handled by a custom
enc_hook/dec_hook(see https://jcristharif.com/msgspec/extending.html).We could add native support for attrs objects, but I'm not sure it'd be worth the (large) effort. I'd expect encode speed to be slower than a struct but faster than a dict (for JSON only, for msgpack I'd expect encode performance to be the same as a dict). For decoding into an attrs type, I'd expect performance to be slower than decoding into a dict, but faster than supporting attrs via a
dec_hook.Since Struct types are always fast, and are similar to attrs/dataclasses, I'm reluctant to spend a ton of effort supporting alternative class types when a faster option already exists. I'd recommend people make use of
enc_hook/dec_hookfor attrs/dataclasses support until they can transition to using struct types instead.Fix `Meta(pattern=..)` memory leak / corruption (msgspec#1256)