K. Richard Pixley
rich at noir.com
Fri Oct 30 19:29:46 CET 2009
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
* 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]'
> from psycopg2 import connect
> except ImportError:
> from myproject import other_modules # you get the idea
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Baypiggies