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

Imports inside functions #188

Open
JuliaKukulies opened this issue Oct 21, 2022 · 4 comments
Open

Imports inside functions #188

JuliaKukulies opened this issue Oct 21, 2022 · 4 comments
Assignees
Labels
Refactor Code that doesn't intend to change the functionality, but instead refactor/clean up. to be deleted?
Milestone

Comments

@JuliaKukulies
Copy link
Member

I realized that we are currently quite inconsistent with importing modules in functions vs. importing modules at the top of the tobac modules. An example is that in some modules, we import numpy at the top whereas in other modules it is imported in every single function.

It is not the most important, but at some point, we should maybe discuss and agree on a rule for this and go through all files to remove redundant imports. Keeping most imports at the top of the file would have a few advantages:

  • PEP8 compliant
  • easier to keep track of which imports are needed for which module
  • probably more efficient (especially when functions are called frequently, e.g. for every timestep/threshold/feature)
  • potential ImportErrors are raised immediately before any code is run

Any thoughts?

@JuliaKukulies JuliaKukulies added the question Queries about using tobac or how the code works label Oct 21, 2022
@freemansw1
Copy link
Member

I think switching to imports at the top of functions, in general, makes sense. The two situations where I see where importing inside functions as advantageous are:

  1. If a feature is optional, clearly the import should be inside a function.
  2. If an import is of a common name (e.g., imports of the form from x import y, where y is some common name). We should probably avoid these in general, but if we can't/don't, these should be as limited in scope as possible.

I'd be happy to see a refactor here, but given our code coverage is ~30-40%, we will have to be very careful that we don't break anything.

@JuliaKukulies
Copy link
Member Author

Thanks for your thoughts @freemansw1! I agree with the two situations you mention where it makes sense to keep the imports inside functions instead of at the top of modules.

Good point about the test coverage. So maybe a way to go would be to only refactor functions that are covered and functions that are added to the modules from now (but this could also result in a mess and we would have redundant imports during some time) or we simply see this as a more long-term goal after we have increased coverage, which is certainly more important than this.

@freemansw1
Copy link
Member

So while our overall code coverage number is pretty poor, our code coverage on the most important modules (feature detection, segmentation, tracking) is actually pretty good. I wouldn't be opposed to switching those functions to module-level imports, and then we can worry about the other modules later, especially as I think we plan on deprecating a lot of those functions.

@JuliaKukulies
Copy link
Member Author

OK, that sounds good. I can have a look into that.

@JuliaKukulies JuliaKukulies self-assigned this Oct 24, 2022
@JuliaKukulies JuliaKukulies added the enhancement Addition of new features, or improved functionality of existing features label Oct 24, 2022
@JuliaKukulies JuliaKukulies added this to the Version 1.5 milestone Oct 24, 2022
@freemansw1 freemansw1 added Refactor Code that doesn't intend to change the functionality, but instead refactor/clean up. and removed enhancement Addition of new features, or improved functionality of existing features question Queries about using tobac or how the code works labels Nov 29, 2022
@freemansw1 freemansw1 modified the milestones: Version 1.5, Version 1.6 Dec 2, 2022
@fsenf fsenf modified the milestones: Version 1.6, Beyond v1.6 May 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Refactor Code that doesn't intend to change the functionality, but instead refactor/clean up. to be deleted?
Projects
None yet
Development

No branches or pull requests

4 participants