-
Notifications
You must be signed in to change notification settings - Fork 4
Open
Description
The QBase
and QEnum
classes have been introduced to avoid having MSONable
classes, if the clien application doesn't want it to be that way. This has apparently been recognised as a limiting factor for adoption of MSONable
objects by other projects.
Hower this choice has some negative consequences on the qtoolkit implementation. This issue is meant for discussion of how the optional MSONable
inheritance is implemented and for the problems related to it.
Currently known issues:
- it is not possible to depend on monty for other functionalities, as this would make
QBase
MSONable
. - mypy does not support dynamic subclasses and this requires to adding a number of
type: ignore
in the code to avoid mypy errors.
Potential solutions for some of these issues and their related dowsides:
- do not rely on the presence of monty for deciding if the base class should be
MSONable
, but rather on some configuration variable. Not very practical. - just implement the
as_dict
andfrom_dict
methods inQBase
. Monty does some duck typing in (de)serializing, so most of the Monty related features would still work. This does not solves security concerns for automatic serialization. - Drop the requirement for the objects to be
MSONable
and just allow some serialization of the objects if needed. - Make the objects
MSONable
and dropQBase
andQEnum
Metadata
Metadata
Assignees
Labels
No labels