1

In a python project I would like to globber imports into a single file called common_imports.py in order to reduce number of import statements in python files. Instead of writing

file1.py

import foo 
import bar
import baz

[...]

file2.py

import foo 
import bar
import baz

[...]

I would like to write

file1.py

from common_imports import *

[...]

file2.py

from common_imports import *

[...]

common_imports.py

import foo 
import bar
import baz

However, this gives me a lot of pylint false positives.

I can disable pylint warnings in the common_imports.py file by adding a pylint disable comment. I can disable wildcard imports. Unfortunately, I can disable unused imports only globally but not specific for all imports from common_imports.py. Somebody has an idea howto get pylint on the track?

S3DEV
  • 8,768
  • 3
  • 31
  • 42
Wör Du Schnaffzig
  • 988
  • 5
  • 23
  • 1
    Pylint is telling you your preferred style is awful. You should listen. – Kurtis Rader Mar 30 '22 at 18:31
  • Can you please be a little bit more elaborate? 1.) I was trying to remove repetition following DRY and 2.) I like to do things once and use many. In the first case, having 10 modules, each having the same three imports results inherently in 10-fold repetition. In the second case, when using the same standard packages again and again do you always want to set-up the same imports in every module you start to write or do you want to create a source file with all those imports once and use it again and again? – Wör Du Schnaffzig Mar 30 '22 at 19:36
  • Former negatively affects maintainability in that splitting one imported module results in 10 places needing modification. – Wör Du Schnaffzig Mar 30 '22 at 19:43
  • (Personally) I understand where you’re coming from in “write it once, use it many”. I get it. *However*. Python convention, it all its organised glory and documented structure, states that if you use a library in a module, *import it in the module*. Plain and simple. Any derivation from this convention is (likely to be) frowned upon. At a lower level, the `sys.modules` `dict`, which tracks the imports will only import a library if it hasn’t been imported already. So from an efficiency point of view, there is no gain. Just the respect (or lack of) from maintainers who follow you. ;-) – S3DEV Mar 30 '22 at 21:09
  • Additionally (ya, me again, sorry) I’d strongly argue your ‘maintainability’ perspective. In that if code is changed / optimised in a module, thus alleviating the need for a specific import … remind me where I look to find where that library is imported? Oh ya, here. But this other module needs that import, but not this new one I’m using to optimise this code. Ugh!!! (Again, the respect / lack thereof of following maintainers …) – S3DEV Mar 30 '22 at 21:12
  • 2
    OK, I see your points and I don't want to be insistive. Lesson learned. I'll put my imports back into place. I just want to add that I'm used to linting and I normally listen to what the linter says. E.g., I made the experience that I can identify bugs others overlook just by using the linter. – Wör Du Schnaffzig Mar 31 '22 at 07:26
  • 1
    Huge fan of pylint myself. Happy coding! :-) – S3DEV Mar 31 '22 at 07:36

1 Answers1

2

Summarising my comments above into a proper answer:

TL;DR:

While the reusable code motive is commendable, it's not fit for purpose here. Listen to the linter, and save your hard-earned respect among your colleagues. :-)

Pythonic Viewpoint:

  • Don't

  • Why? Python convention, in all its organisational glory and documented structure, states that if you use a library in a module, import it in the module. Plain and simple.

    Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.

    -- PEP8 - Imports

  • At a lower level, the sys.modules dict, which tracks imports, will only import a library if it hasn’t been imported already. So from an efficiency point of view, there is no gain.

Maintainer's Viewpoint:

  • Don't
  • Why? If (when) the code is changed / optimised in a module, thus alleviating the need for a specific import … "remind me where I look to find where that library is imported? Oh ya, here. But this other module needs that import, but not this new library I’m using to optimise this code. Where should I import that? Ugh!!!"
    • You've lost the hard-earned respect of following maintainers.
S3DEV
  • 8,768
  • 3
  • 31
  • 42