Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limitations of QBase and QEnum #8

Open
gpetretto opened this issue Mar 21, 2023 · 0 comments
Open

Limitations of QBase and QEnum #8

gpetretto opened this issue Mar 21, 2023 · 0 comments

Comments

@gpetretto
Copy link
Contributor

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 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant