reszelaz
commented
4 years ago I think that TEP17 section: High level plot widgets & compatibility with the old classes answers on the API compatibility:
In terms of backwards compatibility with the existing classes, we aim for feature-compatibility, but not for full API-compatibility. Providing full API compatibility would be difficult in some cases, would clutter the plot classes and would result in workflows that are not natural in the context of pyqtgraph. Still, the simplest use cases with the old classes (e.g. instantiating a plot and calling setModel) should work identically in the new high-level classes. This should allow a large majority of the GUIs to do the switch by just replacing an old plot class by a new one.
For not inheriting of TaurusWidget maybe the idea of duck typing could be used instead of type checking?
This question was asked by @sergirubio during some internal discussions at ALBA but I though it may be of interest of others to hear the answer. Basically: "Why TaurusPlot is not a subclass of TaurusWidget?". In his case he has some application based on the old qwt TaurusPlot and switching to taurus_pyqraph is not as easy as plug-and-play the new class.