Suggestion: Automatically handle types that provide a from_dict and to_dict method about typedload HOT 10 CLOSED

I'm not sure what you mean with the utility class.

from typedload.

It's supposed to be an interface / abstract class. The user can inherit from it to provide the serialization/deserialization functions within their class. The handler could then just check if issubclass(T, LoadDumpable) then use the member functions.

(Also i realized since the value is not necessarily a dict the functions should probably be called something like from_untyped and `to_untyped instead.)

from typedload.

I could add a property like "serializer methods", none by default, that look for those names in the objects and calls them. I'm a bit afraid if people have to_dict that do other unrelated stuff :D I wouldn't want to call it by default.

from typedload.

What about objects that use a constructor to do that?

Would it be easier to add a decorator that tells typedload to use that method as a non-recursive loader?

from typedload.

I could add a property like "serializer methods"

Another issue I didn't think about is that the interface of the method should probably not be as simple as I wrote above since you'll want to be able to receive the loader / dumper instance as well. So i don't think allowing arbitrary function names would work too well, because the interface of the function would be pretty specific.

So right now I think inheriting from a abstract class would be the best solution. That way you also don't have any issue of accidentally calling the wrong function and the whole thing can be enabled by default. Here's the full code I'm using:

def issubclass_safe(sub: Any, sup: type) -> bool:
    """check if sub is a subclass of sup, without making any assumptions about the type of sub"""
    if typing.get_origin(sub) is not None:
        # is an instantiation of a generic type, so compare also the unparameterized type
        if issubclass_safe(typing.get_origin(sub), sup):
            return True
    return inspect.isclass(sub) and issubclass(sub, sup)


class LoadDumpable:
    """class that provides it's own load and dump methods"""

    @staticmethod
    @abstractmethod
    def from_untyped(selftype: Any, loader: dataloader.Loader, data: Any) -> Any:
        "selftype is the generic instantiation of the class type. @classmethod only provides the current class but not the generic instantiation"
        raise NotImplementedError("no implementation")

    @abstractmethod
    def to_untyped(self, dumper: datadumper.Dumper) -> dict[Any, Any]:
        raise NotImplementedError("no implementation")


loader.handlers.append(
    (
        lambda t: issubclass_safe(t, LoadDumpable),
        lambda loader, value, ty: ty.from_untyped(ty, loader, value),
    )
)
dumper.handlers.append(
    (lambda v: isinstance(v, LoadDumpable), lambda dumper, value: value.to_untyped(dumper))
)

What about objects that use a constructor to do that?

The constructor is sometimes used for this, but not always -- so here the from_untyped method would call the constructor

Would it be easier to add a decorator that tells typedload to use that method as a non-recursive loader?

Maybe, but I don't think that would really be much more convenient than adding a specific function that then calls whatever other function the user already has.

from typedload.

Eh in my view a from_dict should be self sufficient and not require typedload. Otherwise it should be an handler function that should do this job, since handlers are typedload-aware.

from typedload.

That also makes sense, I guess. In my case my code base uses typedload in multiple places anyways, and my main reason for wanting this is that I don't want to register handlers for each class that can be serialized separately as well as for all possible loader instances. But I do need the loader instance in the from_untyped function of at least one of those classes (for deserialization of an inner member).

from typedload.

an advantage of a decorator might be that it could detect whether or not the method accepts a loader argument so it could be made optional. But with a decorator the from_dict method is again not really self-sufficient

from typedload.

You can just do an handler that checks if "from" method is present like you sent me and calls it with whatever parameters you want. The function is called with the loader the type and the value to load, so you can then just call your object and decide if you want to pass the loader or not. But all of this is not very generic so I don't think it would make much sense to add it in this form.

I have used such handlers myself at work, but normally never passing the loader object or the type, but just calling type(**data) or type.from_dict(data).

Yeah another problem if it should be called normally or with **

from typedload.

No clear definition of what this should do. Closing.

from typedload.