Coerce a `None` value to the default about msgspec HOT 7 OPEN

I don't disagree - big fan of immutable data structures, and the explicit > implicit is true for sure. However - that's the json i got! msgspec is so much faster than pydantic that i gotta ask, at least.

from msgspec.

One thing you could do now is to have a "private" field with optional list and a property that isn't optional.

from msgspec.

That's actually the direction i went, but the setters and append was all a little bit beyond the level of hackery I was willing to commit. If it was a read-only field, the private optional field and non-optional @property would work great. I was going to try to write some sort of helper class that would act like a list and support append, but eh. A bridge too far. Thanks for taking the time to reply though, I appreciate it!

from msgspec.

no prob. I am a big "immutables" fan, so wasn't thinking about the need for mutable fields.

another idea for you then - you can have phantom types, just for deserialization, which will have optional fields and post_init logic. Then you'll just convert from them to the final type to be used in the code. This can be easily automated, either via code generation (explicit approach), or you could even play around with generating the phantom types from the "true" types on the fly

on the topic, I think all the implicit logic, like treating nulls as missing value, is more headache then gain in the long run. pydantic was (or maybe still is) is so confusing with None/Optional handling. As PEP20 says - Explicit is better than implicit.

from msgspec.

One thing you could do now is to have a "private" field with optional list and a property that isn't optional.

Something like this right?

from msgspec import Struct

class Example(Struct, frozen=True):
    raw: str | None = ""
    
    @property
    def final(self) -> int:
        return self.raw or ""

Yeah I guess users of this class would find it surprising to set raw, but use final

from msgspec.

another idea for you then - you can have phantom types, just for deserialization, which will have optional fields and post_init logic. Then you'll just convert from them to the final type to be used in the code.

@mishamsk do you mean like this? I might have misunderstood

from msgspec import Struct

class Example(Struct, frozen=True):
    x: str

class DecodableExample(Struct, frozen=True):
    x: str | None = ""
    
    def finalize(self) -> Example:
        return Example(x=self.x or "")

I think this is OK, but the ergonomics aren't great when this type is nested in a deep structure. I think you would end up copying every class above it, like this:

class Parent(Struct, frozen=True):
    ex: tuple[Example, ...]

class DecodableParent(Struct, frozen=True):
    ex: tuple[DecodableExample, ...]
    
    def finalize(self) -> Parent:
        return Parent(ex=tuple(e.finalize() for e in self.ex))

import msgspec
msgspec.json.decode(b'{"ex":[{"x":null}]}', type=DecodableParent).finalize()
# Parent(ex=(Example(x=''),))

I often want to coerce a None to the default value in decoding - I prefer not to use union types with None as I find it leads to a proliferation of None checking code.

from msgspec.

@jack-mcivor yes, that's what I roughly meant. Agree that it is not ideal, and for deeply nested models almost beats the purpose of msgspec...

from msgspec.