PyLance does not appreciate @serializable.serializable_class

[whardier]

Inadvertantly opened this ticket half way through writing the subject.

PyLance thinks that serializable.serializable_class decorated classes are untyped. I'm unsure if there is a proper way to resolve type based issues. The "fix" seems to be to have one undecorated class and one decorated class that references the former: i.e. "MyThing" and "SerializableMyThing" in order to allow for casting in individual programs.

Looking forward to some insight on this. CycloneDX-Python-Lib makes use of this library and it can be a bit cumbersome to work with classes provided by that library. Attempting to cast falls into the same trap.

[whardier]

I'm not sure if this is entirely compatible, or proper, but it helped. I think wrapt might magic this away somehow a well.

diff --git a/serializable/__init__.py b/serializable/__init__.py
index 4f9d00f..98700b8 100644
--- a/serializable/__init__.py
+++ b/serializable/__init__.py
@@ -1083,10 +1083,10 @@ def serializable_enum(cls: Optional[Any] = None) -> Any:
     return wrap(cls)
 
 
-def serializable_class(cls: Optional[Any] = None, *, name: Optional[str] = None,
+def serializable_class(cls: Optional[_T] = None, *, name: Optional[str] = None,
                        serialization_types: Optional[Iterable[SerializationType]] = None,
                        ignore_during_deserialization: Optional[Iterable[str]] = None
-                       ) -> Any:
+                       ) -> _T:
     """
     Decorator used to tell ``serializable`` that a class is to be included in (de-)serialization.
 

[whardier]

Checking in on this to see if this is a patches welcome situation or if the CycloneDX Python Lib is considering another serializer.

[jkowalleck]

Hi, I am the current maintainer of CycloneDX Python Lib.
The situation is the following: I'd love to use another serializer in CycloneDX Python Lib, but I do not have the time to work on this topic at the moment.

I also gained maintainer privileges on this very library here, too.

This brings us to the situation where patches are welcome, @whardier :-)