[Baypiggies] Suggestions?

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
      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.

--rich

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20091030/fe676d5a/attachment.htm>


More information about the Baypiggies mailing list