thanks

In theory, under a production setup, the module containing your views
will be initialized only once per server process, and will remain in
memory for the life of the server process (so, for example, if you
have one server process with MaxRequestsPerChild set to "100", it
would be initialized once per 100 HTTP requests).

In practice, it may be initialized multiple times depending on how
you've written your code, specifically depending on the import
statements being used.

When you type, for example::

    from myapp.views import some_view

for the first time, Python will locate the necessary file and
initialize it by executing the code within; this will define the view
functions, and also define your global variable. Then the resulting
object (a live Python module object) will be inserted into the
dictionary "sys.modules" under the key "myapp.views". Later, if you
import again, Python will find "myapp.views" as a key in "sys.modules"
and use the already-initialized module object there.

The problem is that if you later do, say::

    from myproject.myapp.views import some_view

then Python will be looking in "sys.modules" for the key
"myproject.myapp.views", which won't exist; it will go out and find
the file again, initialize it again, and store the resulting module
object in "sys.modules" under the key "myproject.myapp.views".

The net result is that Python will initialize the module once for each
different "path" (e.g., "myapp.views", "myproject.myapp.views", etc.)
you use in an import statement. This is, incidentally, what trips up
so many people with newforms-admin at the moment -- when they
reference the same module in a different way, it gets initialized
again and triggers an error as a model tries to re-register its admin
interface.

To avoid this, ensure that you use import statements consistently.

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."