Are there any reasons Pydantic isn't supported yet?

[martincpt]

I saw a post on Reddit where the OP claimed that he is working on Pydantic integration. What happened with this?

I just tried it without any luck. I'd love to see Pydantic supported.

[Ananto30]

I chose Msgspec over Pydantic. If you still think Pydantic is needed welcome for contribution :)

[martincpt]

@Ananto30

I've added Pydantic support via a custom encoder. The question is, how would you like me to add this for PR? There are two ways of doing this.

1. On top of Msgspec Encoder.

My solution is built on top of the current Msgspec encoder and uses the established functionalities. It can be extended to be generic so that it provides Pydantic support immediately.

Let me show you what I currently have.

try:
    from pydantic import BaseModel

    PYDANTIC_AVAILABLE = True
except ImportError:
    PYDANTIC_AVAILABLE = False

import msgspec
from typing import Any, TypeVar

T = TypeVar("T")

# Have to put here to make it fork-safe
encoder = msgspec.msgpack.Encoder()
decoder = msgspec.msgpack.Decoder()


class PydanticEncoder:
    def encode(self, data: Any) -> bytes:
        if PYDANTIC_AVAILABLE and isinstance(data, BaseModel):
            data = data.model_dump()
        return encoder.encode(data)

    def decode(self, data: bytes) -> Any:
        return decoder.decode(data)

    def decode_type(self, data: bytes, typ: type[T]) -> T:
        if PYDANTIC_AVAILABLE and issubclass(typ, BaseModel):
            data = decoder.decode(data)
            return typ.model_validate(data)
        return msgspec.msgpack.decode(data, type=typ)

This solution could potentially replace the existing one.

2. Separate Pydantic Encoder

Of course, the other option is to completely separate it into its own module and have an additional Pydantic encoder. This way, users would have to explicitly import this encoder and the product would not provide Pydantic support "out of the box".

Furthermore, it appears I need to figure out a way to include Pydantic base models in the allowed types.

Which approach do you prefer? I'm happy to contribute.

[Ananto30]

Hi @martincpt, thanks for the contribution! Good point, I think the first approach is better because it will be out of the box indeed. But I didn't want to pin versions, and Pydantic v1 and v2 has huge differences. What's your opinion on that?

I made the server and client in a way that you can have you own encoder and use that as a plugin. Why do you think attaching Pydantic explicitly to Zero will have more benefits?

[martincpt]

I think Pydantic should be treated as an optional dependency (i.e., pip install zeroapi[pydantic]), which is why I initially handled the ImportError.

That said, I'm not entirely convinced that avoiding version pinning altogether is the best idea. At the very least, the supported version range should be clear — for example, pydantic>=2.0 or using caret notation like ^2.0. You're absolutely right about the significant differences between V1 and V2. For now, I'd be happy to ship with V2 support and consider adding V1 compatibility later if there's demand.

As for the first approach — layering Pydantic support on top of the default encoder — I wonder if it would make sense to rename it to something more generic, like GenericEncoder, instead of MsgspecEncoder.

Separating the two encoders could make sense too, especially while they are still in the experimental stage.

What do you think?

[Ananto30]

Probably we can expose a new GenericEncoder and keep MsgspecEncoder as is. Default can be the GenericEncoder.

About the version pinning, we can introduce it but then what will happen to the existing users?

[martincpt]

I opened a PR with a version-independent solutions. Please take a look. :)