Inconsistent Application of serialization_strategy

[peterallenwebb]

• mashumaro version: 3.2 and 3.3
• Python version: 3.10
• Operating System: macOS

Description

There is an apparent regression in serialization behavior when the serialization_strategy object is being used and there are multiple properties of the same type on the class being serialized. It worked as I expected in 3.1.1, but fails in 3.2 and 3.3.

If the existing unit test test_config.test_serialization_strategy is modified to include a third property called c of type str, it will fail to properly deserialize c. Here's what the modified test looks like in full:

def test_serialization_strategy():
    class TestSerializationStrategy(SerializationStrategy):
        def serialize(self, value):
            return [value]

        def deserialize(self, value):
            return value[0]

    @dataclass
    class DataClass(DataClassDictMixin):
        a: int
        b: str
        c: str

        class Config(BaseConfig):
            serialization_strategy = {
                int: TestSerializationStrategy(),
                str: {
                    "serialize": lambda v: [v],
                    "deserialize": lambda v: v[0],
                },
            }

    instance = DataClass(a=123, b="abc", c="abc")
    assert DataClass.from_dict({"a": [123], "b": ["abc"], "c": ["abc"]}) == instance
    assert instance.to_dict() == {"a": [123], "b": ["abc"], "c": ["abc"]}

It appears to fail because the custom serialize/deserialize methods are called for b, but not for c.

AssertionError: assert test_serialization_strategy.<locals>.DataClass(a=123, b='abc', c=['abc']) == test_serialization_strategy.<locals>.DataClass(a=123, b='abc', c='abc')

[peterallenwebb]

This appears to be happening because mashumaro.core.meta.code.builder.CodeBuilder.__iter_serialization_strategies() is decorated with @lru_cache. The generator returned by this function is being cached and then iterated, but the same generator is returned again on subsequent calls. Removing @lru_cache is an easy fix and I would be happy to prepare a PR, but I'm not sure of the overall performance implications.

[Fatal1ty]

Using a decorator @lru_cache for a generator function was a stupid mistake. I wanted to cache result because iter_serialization_strategies is called for each dataclass field on compilation time but now I see what it led to. We should replace a generator function __iter_serialization_strategies with a function returning first not-none strategy found and keep it cached:

@lru_cache()
@typing.no_type_check
def __get_serialization_strategy(self, ftype: typing.Type) -> typing.Optional[SerializationStrategyValueType]

I can return back to coding next week when my vacation ended. You can prepare your existing PR or let me fix this issue myself. Anyway thank you for spotting this bug and I hope it didn’t do anything bad in your production code.

[Fatal1ty]

@peterallenwebb I decided to accept your PR instead of relying on the type objects to always be hashable. Thank you for your contribution!

[Fatal1ty]

Fixed in 3.3.1.