You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a recent refactoring of ARIMA/Prophet, the TargetLeakageDataCheck.validate() was invoked. The invocation looks like:
From a dev perspective, this is OK. It's not particularly clear or simple and implies some arcane nested structure being returned for validate() that might be worth refactoring into a class or namedtuple to make a bit simpler.
In #3072 , we discuss a similar refactoring that might help make the OS user experience easier. Completing said story also might allow us to refactor away some of these less-clear portions of our code that require an implied innate knowledge of the return structure.
Acceptance criteria: this story will close after #3072 is addressed. If a different return structure is decided for the .validate() functions of the DataChecks, then closing this story involves refactoring the code from the linked PR and filing an issue to further identify and refactor areas of our code that dig through the output of .validate().
The text was updated successfully, but these errors were encountered:
@chukarsten I don't see the original code in the repo now but after #3072 and the rest of the data check API refactor, validate() no longer returns the same structure: it returns a list instead of a dict. This might make it a bit more difficult to get the exact warning / message we expect but then getting the metadata / action is slightly different. Closing for now, we can reopen using the new structure if we still see area for improvement!
In a recent refactoring of ARIMA/Prophet, the
TargetLeakageDataCheck.validate()
was invoked. The invocation looks like:From a dev perspective, this is OK. It's not particularly clear or simple and implies some arcane nested structure being returned for
validate()
that might be worth refactoring into a class or namedtuple to make a bit simpler.In #3072 , we discuss a similar refactoring that might help make the OS user experience easier. Completing said story also might allow us to refactor away some of these less-clear portions of our code that require an implied innate knowledge of the return structure.
Acceptance criteria: this story will close after #3072 is addressed. If a different return structure is decided for the
.validate()
functions of the DataChecks, then closing this story involves refactoring the code from the linked PR and filing an issue to further identify and refactor areas of our code that dig through the output of.validate()
.The text was updated successfully, but these errors were encountered: