Currently, clintest uses clingo.solving.Model quite prominently. This has two major drawbacks:
One cannot persist models for later use as clingo.solving.Model references some clingo internal data that vanishes once the search continues.
One cannot create a model without using clingo.control.Control.solve. This implies nobody can use solver that is not based on clingo.
This problem could perhaps be solved by adding our own model API, i.e., an abstract class clintest.model.Model. For clintest.model.Model we could add a wrapper or resort to some kind of duck typing.
Currently, clintest uses
clingo.solving.Modelquite prominently. This has two major drawbacks:clingo.solving.Modelreferences some clingo internal data that vanishes once the search continues.clingo.control.Control.solve. This implies nobody can use solver that is not based on clingo.This problem could perhaps be solved by adding our own model API, i.e., an abstract class
clintest.model.Model. Forclintest.model.Modelwe could add a wrapper or resort to some kind of duck typing.