Organize imports & dependencies #15
Conversation
Imports should be on separate lines. Imports should be grouped with the order being most generic to least generic: - standard library imports - third-party imports - application-specific imports Be consistent in use of `from X import Y` versus `import X`. Source: https://google-styleguide.googlecode.com/svn/trunk/pyguide.html
If we compare the output of the bash function `list_imports` defined below to
the contents of requirements.txt, we see that we have a bunch of required
modules that are actually never imported... We can get rid of these modules to
make the initial setup of the project easier.
```
list_imports() {
grep -E '^(import\s.*|from\s.*import)' *.py \
| cut -f2 -d':' \
| cut -f2 -d' ' \
| cut -f1 -d'.' \
| sort -u
}
```
This project isn't doing anything particularly fancy meaning that we don't need to depend on the bleeding edge versions of our requirements i.e. we can use the slightly older versions of scikit-learn, pandas and scipy that are available pre-compiled in the package repositories of many Linux distributions. This makes the project easier to set up and therefore more approachable.
|
Thanks, will merge later today or tomorrow. (on phone now)
|
There was a problem hiding this comment.
Are you using the from imports for external imports, and import MODULE_NAME for internal modules? Is this a recommended style? (not questioning, just curious)
There was a problem hiding this comment.
A rule of thumb that I've seen thrown about here and there and that makes sense to me is to try to stick to import X for standard library imports (familiarity, name-spacing) and to use from X import Y for third party code which tends to have lots of nested modules (e.g. SciKit) and where classes are generally speaking already name-spaced (e.g. DataFrame is very recognizably from Pandas).
Organize imports & dependencies
2 participants
Some changes to make the project more readily accessible:
requirements.txtand make required versions more lenient.