1997-08-30 22:02:25 +02:00
|
|
|
\section{Standard Module \sectcode{user}}
|
|
|
|
\label{module-user}
|
|
|
|
\stmodindex{user}
|
1998-01-13 19:45:34 +01:00
|
|
|
\indexii{.pythonrc.py}{file}
|
|
|
|
\indexiii{user}{configuration}{file}
|
1997-08-30 22:02:25 +02:00
|
|
|
|
|
|
|
As a policy, Python doesn't run user-specified code on startup of
|
|
|
|
Python programs. (Only interactive sessions execute the script
|
1997-12-09 20:46:45 +01:00
|
|
|
specified in the \code{PYTHONSTARTUP} environment variable if it exists).
|
1997-08-30 22:02:25 +02:00
|
|
|
|
|
|
|
However, some programs or sites may find it convenient to allow users
|
|
|
|
to have a standard customization file, which gets run when a program
|
|
|
|
requests it. This module implements such a mechanism. A program
|
|
|
|
that wishes to use the mechanism must execute the statement
|
|
|
|
|
1998-01-09 23:27:55 +01:00
|
|
|
\begin{verbatim}
|
1997-08-30 22:02:25 +02:00
|
|
|
import user
|
1998-01-09 23:27:55 +01:00
|
|
|
\end{verbatim}
|
1997-08-30 22:02:25 +02:00
|
|
|
|
1997-12-16 15:41:36 +01:00
|
|
|
The \code{user} module looks for a file \file{.pythonrc.py} in the user's
|
1997-08-30 22:02:25 +02:00
|
|
|
home directory and if it can be opened, exececutes it (using
|
|
|
|
\code{execfile()}) in its own (i.e. the module \code{user}'s) global
|
|
|
|
namespace. Errors during this phase are not caught; that's up to the
|
1997-12-16 15:41:36 +01:00
|
|
|
program that imports the \code{user} module, if it wishes. The home
|
1997-08-30 22:02:25 +02:00
|
|
|
directory is assumed to be named by the \code{HOME} environment
|
|
|
|
variable; if this is not set, the current directory is used.
|
|
|
|
|
|
|
|
The user's \file{.pythonrc.py} could conceivably test for
|
|
|
|
\code{sys.version} if it wishes to do different things depending on
|
|
|
|
the Python version.
|
|
|
|
|
|
|
|
A warning to users: be very conservative in what you place in your
|
|
|
|
\file{.pythonrc.py} file. Since you don't know which programs will
|
|
|
|
use it, changing the behavior of standard modules or functions is
|
|
|
|
generally not a good idea.
|
|
|
|
|
|
|
|
A suggestion for programmers who wish to use this mechanism: a simple
|
|
|
|
way to let users specify options for your package is to have them
|
1997-12-16 15:43:37 +01:00
|
|
|
define variables in their \file{.pythonrc.py} file that you test in
|
1997-08-30 22:02:25 +02:00
|
|
|
your module. For example, a module \code{spam} that has a verbosity
|
|
|
|
level can look for a variable \code{user.spam_verbose}, as follows:
|
|
|
|
|
|
|
|
\bcode\begin{verbatim}
|
|
|
|
import user
|
|
|
|
try:
|
|
|
|
verbose = user.spam_verbose # user's verbosity preference
|
|
|
|
except AttributeError:
|
|
|
|
verbose = 0 # default verbosity
|
|
|
|
\end{verbatim}\ecode
|
|
|
|
|
|
|
|
Programs with extensive customization needs are better off reading a
|
|
|
|
program-specific customization file.
|
|
|
|
|
|
|
|
Programs with security or privacy concerns should \emph{not} import
|
|
|
|
this module; a user can easily break into a a program by placing
|
|
|
|
arbitrary code in the \file{.pythonrc.py} file.
|
|
|
|
|
|
|
|
Modules for general use should \emph{not} import this module; it may
|
|
|
|
interfere with the operation of the importing program.
|
|
|
|
|
1998-01-13 19:45:34 +01:00
|
|
|
\begin{seealso}
|
|
|
|
\seemodule{site}{site-wide customization mechanism}
|
1997-12-16 15:41:36 +01:00
|
|
|
\refstmodindex{site}
|
1998-01-13 19:45:34 +01:00
|
|
|
\end{seealso}
|