I thought: Well, isn't it a bit redundant if I go ahead and say in my
config "import this-n-that and temp and load and alsa" while later
just giving register() the modules.
So register() (/ClassFinder as the backend) now support just naming a
module as the first parameter. That module is then imported and
searched for a class as usual.
Just for reference the synopsis of Status.register():
register(mod.SomeChecker())
register(mod, setting1=..., setting2=...)
register(mod, {"setting1:":, "setting2":...})
register("mod", setting=1..., setting2=...)
register("mod", {"setting1:":, "setting2":...})
Fun fact: Actually register() doesn't care for it's arguments.
They're passed straight into ClassFinder.instanciate_class_from_module
(something I should definitely rename), which checks if it's first
parameter is one of:
-Python module
=> It calls ClassFinder.get_class with the same parameters
=> get_class will search the module using ClassFinder.search_module
and return a matching class if and only if there is a single matching
class in the module
-string
=> It calls ClassFinder.get_module to import the module and calls itself
on the result
-something else
=> It returns that something
The actual variation in passing the settings (keyword arguments vs. dict)
is handled in SettingsBase.
ClassFinder:
Removed exclude argument, which is basically covered with
obj.__module__ == module.__name__ which ensures that no imported
classes are found, which was the only use case for exclude.
This didn't change the public "API" used by modules.
.core.io contains the IO classes, namely IOHandler, StandaloneIO and JSONIO
.core.util contains SettingsBase and ClassFinder
.core.exceptions contains all custom exceptions
