mvoorhie at yahoo.com
Fri Oct 30 20:13:43 CET 2009
I tend to follow the practice in Richard's answer (put imports close the the
code that requires them, move them up in scope as they become more widely
used within a module). Some of my bias for doing this may come from the C++
practice of declaring local variables immediately before their first use. I
would be interested in the reasoning behind the PEP recommendation.
I think that one good reason for resolving imports at the top of the file is
to fail as early (and loudly) as possible if a required component is missing
from the system. For this reason, I start all of my CGI scripts with a piece
of self-contained boilerplate that tries to import the minimum required
modules for the script (in particular, all of the error handling code) and
handles exceptions by writing a generic error page/message to stdout/stderr.
On Friday 30 October 2009 11:29 am K. Richard Pixley wrote:
> Your way looks fine to me.
> I think the PEP is a bit oversimplistic about imports. I think there
> are at least a couple of really good reasons to put imports into the
> code line rather than at the top of the file.
> * in line, the imports are easier to move along with the code when
> refactoring. Done at the top of the file, you essentially end up
> moving the code, then bumping into the missing imports one at a
> time until you get them all. And imports which are no longer
> used, (the ones in the old file), may never be removed which is
> misleading to the point of being confusing as well as potentially
> impacting performance.
> * time. It takes essentially zero time to import an already
> imported module. So importing multiple times is cheap. However,
> the first import takes time - time that we may not need to spend.
> If we delay that cost, we may never need to pay it.
> Personally, I've often been putting many of my imports immediately prior
> to the first use of the thing being imported. But when I have to write
> an import a second time, I usually move the first import up in scope to
> cover both usages. I'll also move an import up in scope if it makes the
> code more readable or moves it out of a loop or other repeated code.
> I can see advantages to top level imports and I use them too for the
> most common imports, (like sys), or for things that I know are going to
> be used pervasively throughout a file. I haven't come to a completely
> comfortable balance for myself between using imports inline and placing
> them at the top of the file. I suspect I will gravitate towards inline
> for early development and things that can potentially be left unimported
> and gravitating towards top-of-file as the code matures.
> Glen Jarvis wrote:
> > Because I've *always* learned something from this community this when
> > posting similar questions, I have the following snippet ..
> > This project is imported on all machines. The organization is one
> > module with reasonably small python files organized logically
> > (backup.py, diskspace.py, shared.py, webserver.py, etc.) These are
> > menu driven management scripts for someone doing operations.
> > In my backup.py file, I have the following imports (organized in
> > groups per PEP-8; http://www.python.org/dev/peps/pep-0008/). However,
> > one of our hosts intentionally doesn't have psycopg2 installed. How do
> > most deal with the conditional import, while still keeping the imports
> > grouped at the top of the file? Or, better yet, how do you deal with
> > this? It's very tempting to break convention and only import psycopg2
> > module in the functions that need it. That seems extreme for just one
> > node in our system, however.
> > The following feels messy to me... I've been living with it, but then,
> > I betcha someone at BayPIGgies has a good suggestion :)
> > from datetime import datetime, timedelta
> > import os
> > import subprocess
> > import sys
> > import tarfile
> > from optparse import OptionParser
> > # There is no psycopg2 on host '[snip]'
> > try:
> > from psycopg2 import connect
> > except ImportError:
> > pass
> > from myproject import other_modules # you get the idea
> > ------------------------------------------------------------------------
> > _______________________________________________
> > Baypiggies mailing list
> > Baypiggies at python.org
> > To change your subscription options or unsubscribe:
> > http://mail.python.org/mailman/listinfo/baypiggies
More information about the Baypiggies