6

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?

  • The case to be made is that it saves typing. Whether that's good is debatable. – immibis Apr 27 '16 at 21:18
  • @immibis I'm actually watching this talk right now, which seems to indicate it isn't all that rare. In fact, I'm finding out even larger projects may not be entirely conformant to pep8 etc. when it comes to importing. Might be able to work out an answer from all this. – mechalynx Apr 27 '16 at 22:07
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.

  • "Instead move as much common code as possible into a common module where BOTH imports AND the code that needs those imports lives" 100% agreed, but that's pretty much what I want to do already. "This will go farther towards removing code duplication than a magic import procedure" as I mentioned, this isn't a magic import procedure, it's just placing imports in a common module. I'm asking because this seems generally frowned upon as being more surprising, not less. I don't agree with the general sentiment, but nonetheless I don't think this answer addresses the consensus arguments. – mechalynx Apr 29 '16 at 1:52
  • @ivy_lynx The consensus arguments bring up two issues. 1) Do not do things in a way that surprises maintainers. Because doing so makes it harder for them to maintain. 2) Avoid action at a distance. When it comes to Python, a common module just for imports causes both surprise for Python programmers, and is action at a distance. (It is not obvious when I see foo in code where that is from and what documentation to learn about it in.) That said, the strength of those arguments depend on who will maintain your code. If just you, then probably not important... – btilly May 2 '16 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.