AFAIK, there are two main use-cases for TaurusWidgetFactory in Taurus:
to retrieve an "official" taurus widget/class from its name (e.g. calling TaurusBaseWidget.getWidgetClass(taurusname) or similar)
to list all "official" taurus widgets/classes (e.g. calling TaurusBaseWidget.getWidgetClasses() or similar)
This presents the following issues:
The first initialization of TaurusWidgetFactory is quite expensive as it introspects and imports all taurus submodules.
The use-case 1 is limited to "official" taurus widgets. Third party taurus-based widgets are not supported.
Proposed changes
Refactor all usages of type 1 in taurus to use importlib instead. Use a syntax similar to that of the entry-points to describe an object ("module:object.attr", where module may optionally be a dotted submodule name and the .attr part is optional)
Try to eliminate all usages of type 2 as well, and if not possible, at least delay them as much as possible to avoid initializing TaurusWidgetFactorywhenever possible.
Add a deprecation warning in the public API of TaurusWidgetFactory
AFAIK, there are two main use-cases for
TaurusWidgetFactoryin Taurus:TaurusBaseWidget.getWidgetClass(taurusname)or similar)TaurusBaseWidget.getWidgetClasses()or similar)This presents the following issues:
TaurusWidgetFactoryis quite expensive as it introspects and imports all taurus submodules.Proposed changes
importlibinstead. Use a syntax similar to that of the entry-points to describe an object ("module:object.attr", wheremodulemay optionally be a dotted submodule name and the.attrpart is optional)TaurusWidgetFactorywhenever possible.