[Baypiggies] Suggestions?

[Mark Voorhies]

  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. 

--Mark

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