Tagging relies on class names exclusively

[magreenberg1]

Hi again!

I currently have some code like...

@serde(tagging=InternalTagging("type"))
@dataclass(frozen=True, kw_only=True)
class ConfigFile:
    items: list[ConfigA | ConfigB]

As far as I can tell, in the config file, items[].type must be either "ConfigA" or "ConfigB" but I'd like to use "A" or "B" in the config file instead. Perhaps we can add a mapping in the Tagging types so we can expect custom values?

Something like...

@serde(tagging=InternalTagging("type", tag_types={"A": ConfigA, "B": ConfigB}))
@dataclass(frozen=True, kw_only=True)
class ConfigFile:
    items: list[ConfigA | ConfigB]

What do you think?

[yukinarit]

Hi @magreenberg1 More serde-API like solution is adding rename class attribute. WDYT?

@serde(rename="A")
@dataclass
class ConfigA:
    value: str

@serde(rename="B")
@dataclass
class ConfigB:
    value: int

[ColladoA]

Also think having this functionality would be useful.

One note/difference I see between the two solutions posted though is:

1. With @serde(rename=...), this would apply to all uses of the class (if it's used in multiple places), so all wrapper classes would use the same mappings.
2. With @serde(tagging=...) it would only apply to the specific class that contains the tagging, so different wrapper classes could use different mappings.

For my purposes at least either would work, but I'm not sure if the second point matters to others.

[magreenberg1]

Hi @yukinarit - Sorry for not responding sooner.

I prefer the ergonomics of @serde(rename="A") but I wonder if it may be a bit limiting.

For example, if we have...

@serde(rename="A")
@dataclass
class ConfigA:
    value: str

@serde(rename="B")
@dataclass
class ConfigB:
    value: int


@serde
@dataclass
class ConfigC:
    value: list[ConfigA, ConfigB]

@serde
@dataclass
class ConfigD:
    value: list[ConfigA, ConfigB]

Both ConfigC and ConfigD would have to rely on the same naming. But if they actually have 2 slightly different schema semantics (maybe ConfigD expects snake case while ConfigC expects camel case) there's no path forward beyond copying the dataclasses. I feel like this is a relatively uncommon situation though.