Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor core.py #1038

Open
seanlaw opened this issue Oct 23, 2024 · 1 comment
Open

Refactor core.py #1038

seanlaw opened this issue Oct 23, 2024 · 1 comment
Labels

Comments

@seanlaw
Copy link
Contributor

seanlaw commented Oct 23, 2024

The core.py file was meant to act as a central utility module where multiple other modules could find common functions. Over time, it has become bloated and it makes sense to move some of the related functions into its own module. For example, it might make sense to have:

  1. gpu_core.py for all GPU-related utilities
  2. process.py/preprocess.py
  3. check.py for functions that "check" the state of an array
  4. rolling.py for anything related to rolling/sliding window computations
  5. distance.py
  6. mcore.py for all multi-dimensional utility functions

It is okay if core.py imports from these other modules and this would reduce the number of changes in our API modules (i.e., our user facing API modules wouldn't change at all as long as they continue importing from core.py). Of course, any refactoring will also involve moving their associated unit tests as well

@seanlaw
Copy link
Contributor Author

seanlaw commented Oct 23, 2024

The first thing would be to come up with a plan, then create separate issues for each new sub-module, and add each issue to a single milestone

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant