Although not yet merged, PR #192 factors constant values into a separate file, and places some groups of constants into Enum classes. Currently, only ProblemType and MetafeatureGroup are defined as enums, but we could potentially do the same for things like column types (like categorical, numeric, etc) or computing error values (like NO_TARGETS, NUMERIC_TARGETS, etc).
We should discuss whether to keep these values separate or combine them into Enums. As a starter, @epeters3 mentioned in the pull request:
I was torn on this idea. Enums are clean and more strict, but when you want to use the actual string of an Enum, i.e. if you want to use the string value "NUMERIC", you have to say ColumnType.NUMERIC.value, rather than consts.NUMERIC. We could restructure all uses of column_types to reference ColumnType enum members instead of strings, and just say ComputeErrors.NO_TARGETS.value in the case of compute errors.
Although not yet merged, PR #192 factors constant values into a separate file, and places some groups of constants into Enum classes. Currently, only
ProblemType
andMetafeatureGroup
are defined as enums, but we could potentially do the same for things like column types (like categorical, numeric, etc) or computing error values (like NO_TARGETS, NUMERIC_TARGETS, etc).We should discuss whether to keep these values separate or combine them into Enums. As a starter, @epeters3 mentioned in the pull request: