Refactor setting of PROPERTIES columns across Modules
#1429
Conversation
…set of Categories, and add class typehints to Property and Module
…e property - was never referenced in the codebase
…ptom_code property - was never referenced in the codebase" This reverts commit 778dc2e.
…t pop. All these modules pass-ed this method. Since there are no properties defined by these modules, this is what the inherited method will do without need to redefine it in the module again.
…nation of what can now be handled automatically
…s being unset to nan, which conflicts with our new default behaviour.
|
I suggest breaking this PR into several PRs. One adding the new functionality, the others refactoring specific modules to use the new functionality. This does mean that we end up supporting both old and new approaches for a time, but it is easier to work with modellers to update and check their modules and also identify any regressions easily. |
No problem, it should just be a case of cherry-picking the various commits from this branch (they're on a per-module basis). Will get started on this. |
|
Closing in favour of (the first of many) starting with #1436. Leaving the branch here for cherry-picking purposes. |
Concerns #1428 |
Large portion of the additions in the diff are the
PROPERTIESattributes of the modules being linted bytox checkand split over multiple lines, so apologies for that to any reviewers.Key changes introduced are within the
coremodule though - specifically the newdefault_valuethatPropertys now take and the abstractly implementedinitialise_populationmethod. Changes to disease modules should mostly be deletions of the explicit setting of columns and addition of default values for categories where necessary.