Common imports between many scripts in Python project

Question

I'm writing an automated installation script for a bunch of software, in Python. The purpose is for the script to fetch compressed files from a directory and install/configure each utility or application on a case-by-case basis.

Since each of these requires special treatment (and when it isn't required it's the exception and I'd rather be ready just in case it does need special treatment in the future), I decided to have a separate .py file for each of them, with the main script automatically detecting which one to use based on name matching, the rules of which are in a central .json file.

A lot of these specific scripts require more or less the same imports, in addition to some that are specific to that file. So I decided that it makes sense, just like we do in languages like C, to have a "header" script which imports the commonly used modules and just import that in all the minor and specific scripts.

However, upon reading several questions on SO (here, here, here and here are a few) it seems the consensus is that you should never do this and instead explicitly import modules on each file, as required. The reasons given are:

1. It's explicit and in line with Python's design philosophy
2. It makes it easier to find dependencies with just a text search

I've considered these but I can't decide if they apply in my case. I will have 50-100 different files, each requiring some common imports and some imports specific to that file. It seems in line with "don't repeat yourself" to put all the common imports in one file and import that file. It also seems less error-prone (what if I change to a different module with the same interface and just need to change the import statement? If it's in one place, I know it's correct everywhere, otherwise I'd need to change it in every file).

Regardless of the details of this specific project, in general, is there ever a good case to be made for a common imports file in Python?

Answer 1

If you're writing code that needs a library, the import for the library is necessarily less code than the code which uses said library. When you put the two together in the same file, it is more likely that changes in one will result in remembering to do the other. Particularly if your editor uses pyflakes to enforce PEP compliance and therefore notices the unused import.

If you're writing many scripts that are very similar, the common import statements are going to be the least of your problems. Instead move as much common code as possible into a common module where BOTH imports AND the code that needs those imports lives. Per script overrides can be implemented with a combination of configuration and subclassing, and those subclasses will be much shorter because of how much common stuff is in the script. This will go farther towards removing code duplication than a magic import procedure, and will surprise maintainers less.