You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 QBaseMSONable.
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 and from_dict methods in QBase. 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 drop QBase and QEnum
The text was updated successfully, but these errors were encountered:
The
QBase
andQEnum
classes have been introduced to avoid havingMSONable
classes, if the clien application doesn't want it to be that way. This has apparently been recognised as a limiting factor for adoption ofMSONable
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:
QBase
MSONable
.type: ignore
in the code to avoid mypy errors.Potential solutions for some of these issues and their related dowsides:
MSONable
, but rather on some configuration variable. Not very practical.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.MSONable
and just allow some serialization of the objects if needed.MSONable
and dropQBase
andQEnum
The text was updated successfully, but these errors were encountered: