Multiple aliases for field about mashumaro HOT 6 OPEN

A related idea is to have the alias(es) depend on the dialect. Depending on the scenario, this may be a somewhat cleaner solution to the above example problem, e.g., if you want to deserialize in of the two ways. It would also help in scenarios where the key used may depend on natural language, e.g., in a scenario where a config file may be given in multiple languages (e.g., it has a key "date" and a German alias "Datum").

@Fatal1ty Do you think this would be a reasonable feature to have?

edit: A less elegant thing would be to handle such things via __post_deserialize__ or __pre_deserialize__ hooks, but unfortunately, they don't take a context. (Is there a specific reason to have the context only for serialization?)

from mashumaro.

@real-or-random In short, I like your idea.

I also thought about configuring aliases in dialects but in a more complex scenario. Right now, it's not possible to use the aliases config option for nested structures, which is why I haven't mirrored it in dialects yet. If there is only one dialect, it would be useful to have aliases for all the fields including those nested in dataclasses or other structures. I imagine something like foo.bar[*].date for a key date in a dictionary-like structure (dataclasses, TypedDicts) within a sequence bar of a dictionary-like structure in the key foo. Or it could be [*].date for a key date of any dictionary-like structure within a sequence when the dialect is being used for codecs that work not only with top level dataclasses.

If you'd like to contribute, we could start with the simple scenario and add support for a path syntax later.

from mashumaro.

Hi @CralixRaev

This would be a useful feature. I think reusing existing alias field option and aliases config option is a good way to go.

The field option would accept Union[str, Sequence[str]] instead of current str. The config option would accept Dict[str, Union[str, Sequence[str]]] instead of current Dict[str, str]

Would you like to work on it? It will be pretty straightforward after upcoming merge of the related PR:

• #175

from mashumaro.

edit: A less elegant thing would be to handle such things via __post_deserialize__ or __pre_deserialize__ hooks, but unfortunately, they don't take a context. (Is there a specific reason to have the context only for serialization?)

Actually, no specific reason here. It was requested just for serialization.

from mashumaro.

If you'd like to contribute, we could start with the simple scenario and add support for a path syntax later.

Thanks for the swift reply! I might need this in the future, but it's further down the road. I'm still in the process of figuring out whether this lib is the right for me, see my other issue. ;)

from mashumaro.

Thanks for the swift reply! I might need this in the future, but it's further down the road. I'm still in the process of figuring out whether this lib is the right for me, see my other issue. ;)

Thank you for your feedback and illustrative examples with German words. This will help me to prioritize what needs to be done first.

from mashumaro.