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

Split kinematics module into multiple files. #327

Open
niksirbi opened this issue Oct 18, 2024 · 0 comments
Open

Split kinematics module into multiple files. #327

niksirbi opened this issue Oct 18, 2024 · 0 comments
Labels
enhancement New optional feature

Comments

@niksirbi
Copy link
Member

Problem

The kinematics.py file is already big, and when the in-progress PRs are merged (especially #315, #277, #280), it will be much bigger, which will make it unwieldy to handle.

Proposed solution

Split the kinematics.py file into multiple modules, for example:

  • kinematics.py: this will contain functions for measuring derivatives - velocity, acceleration, displacement, speed, and perhaps also pairwise distances?
  • navigation.py: this can contain the functions for forward_vector, head_direction_vector, heading, path_length

The first file could also be called derivatives.py, but I don't know if, say, distances would fit neatly in that. I'm open to other (hopefully better) splitting "ontologies".

Despite splitting the files, I propose to still keep a unified kinematics namespace. So to the users, nothing will change. All functions that are currently in kinematics.py will still be importable as from movement.kinematics import function. We can do this by fiddling with the __init__.py files.

Alternative

We could also split the namespace together with the files, so we have movement.kinematics and movement.navigation (or whatever categories we settle for). That could be easily achieved by splitting the files without doing anything in the __init__.py.

But if we go for this option, I'd want the semantic separation to be "clean". If we just separate the files, without affecting the user, we can afford to be fuzzier with our splits.

Additional context

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New optional feature
Projects
Status: 🤔 Triage
Development

No branches or pull requests

1 participant