Lazy imports can be done either explicitly, by moving import statements inside functions (instead of at the global level), or by using tools such as LazyImport from egenix. Here's why they suck:

> fetchall (PgSQL:3227) --> __fetchOneRow (PgSQL:2804) ----> typecast (PgSQL:874) ... 26703 function calls later ... ----< typecast (PgSQL:944): <mx.DateTime.DateTime object for '2005-08-15 00:00:00.00' at 2713120> 3477.321ms

Yes, folks, that single call took 3.4 seconds to run! That would be shorter if I weren't tracing calls, but...ick. Don't make your first customer wait like this in a high-performance app. The solution if you're stuck with lazy imports in code you don't control is to force them to be imported early:

mx.DateTime.Parser.DateFromString('2001-01-01')

Now that same call:

> fetchall (PgSQL:3227) --> __fetchOneRow (PgSQL:2804) ----> typecast (PgSQL:874) ... 7 function calls later ... ----< typecast (PgSQL:944): <mx.DateTime.DateTime object for '2005-08-15 00:00:00.00' at 27cf360> 1.270ms

That's 1/3815th the number of function calls and 1/2738th the run time. I am not missing decimal points.

Not only is this time-consuming for the first requestor, but lends itself to nasty interactions when a second request starts before the first is done with all the imports. Module import is one of the least-thread-safe parts of almost any app, because people are used to expecting all imports in the main thread at process start.

I'm trying very hard not to rail at length about WSGI frameworks that expect to start up applications during the first HTTP request...but it's so tempting.