Best practices with import?

[phawkins at connact.com]

>>>>> "TB" == Tom Bryan <tbryan at python.net> writes:

TB> At least, I see that the timbot is still explaining why
TB> threading.py does this.

TB> import sys
TB> import time
TB> import thread
TB> import traceback
TB> import StringIO

TB> # Rename some stuff so "from threading import *" is safe

TB> _sys = sys
TB> del sys

TB> _time = time.time
TB> _sleep = time.sleep
TB> del time

This kind of thing is useful when writing a module for public
consumption.  A program that imports threading.py isn't going to wind
up with all sorts of time and sys cruft cluttering its namespace, but
the threading module has access to what it needs.  

This is all about managing what kind of cruft winds up in your
namespace, or your user's namespace; managing who it's visible to; and
making sure that it's named so that it does what you expect it to, and
have some clue about where it came from.

The following idiom would do the same thing as the above example from
threading.py, and is rather less verbose.  (I think "import x as y" is
recent, though, maybe 2.0?)

import time.time as _time

Although the threading.py example is specifically useful when one is
writing a module for consumption by others, rather than just your own
program, it's still good practice to import just what you need, rather
than the whole shebang -- unless you need the whole shebang, or --
ahem -- just don't care. 
Avoid outrageous practices like:

import time.time as spam

and, to be kind to future maintainers of your code (for example, you,
next year) try to reveal rather than conceal the origins of what you
import; and don't make the code behave unexpectedly.  

eg:

import spammityspam.open as spamopen

is way better than

import spammityspam.open as open

and 

import spammityspam
spammityspam.open('fxxx')

works fine too, if you're not concerned by the size of the
spammityspam module.
--
Patricia J. Hawkins
Hawkins Internet Applications, LLC