1 | \section{\module{user} ---
|
---|
2 | User-specific configuration hook}
|
---|
3 |
|
---|
4 | \declaremodule{standard}{user}
|
---|
5 | \modulesynopsis{A standard way to reference user-specific modules.}
|
---|
6 |
|
---|
7 |
|
---|
8 | \indexii{.pythonrc.py}{file}
|
---|
9 | \indexiii{user}{configuration}{file}
|
---|
10 |
|
---|
11 | As a policy, Python doesn't run user-specified code on startup of
|
---|
12 | Python programs. (Only interactive sessions execute the script
|
---|
13 | specified in the \envvar{PYTHONSTARTUP} environment variable if it
|
---|
14 | exists).
|
---|
15 |
|
---|
16 | However, some programs or sites may find it convenient to allow users
|
---|
17 | to have a standard customization file, which gets run when a program
|
---|
18 | requests it. This module implements such a mechanism. A program
|
---|
19 | that wishes to use the mechanism must execute the statement
|
---|
20 |
|
---|
21 | \begin{verbatim}
|
---|
22 | import user
|
---|
23 | \end{verbatim}
|
---|
24 |
|
---|
25 | The \module{user} module looks for a file \file{.pythonrc.py} in the user's
|
---|
26 | home directory and if it can be opened, executes it (using
|
---|
27 | \function{execfile()}\bifuncindex{execfile}) in its own (the
|
---|
28 | module \module{user}'s) global namespace. Errors during this phase
|
---|
29 | are not caught; that's up to the program that imports the
|
---|
30 | \module{user} module, if it wishes. The home directory is assumed to
|
---|
31 | be named by the \envvar{HOME} environment variable; if this is not set,
|
---|
32 | the current directory is used.
|
---|
33 |
|
---|
34 | The user's \file{.pythonrc.py} could conceivably test for
|
---|
35 | \code{sys.version} if it wishes to do different things depending on
|
---|
36 | the Python version.
|
---|
37 |
|
---|
38 | A warning to users: be very conservative in what you place in your
|
---|
39 | \file{.pythonrc.py} file. Since you don't know which programs will
|
---|
40 | use it, changing the behavior of standard modules or functions is
|
---|
41 | generally not a good idea.
|
---|
42 |
|
---|
43 | A suggestion for programmers who wish to use this mechanism: a simple
|
---|
44 | way to let users specify options for your package is to have them
|
---|
45 | define variables in their \file{.pythonrc.py} file that you test in
|
---|
46 | your module. For example, a module \module{spam} that has a verbosity
|
---|
47 | level can look for a variable \code{user.spam_verbose}, as follows:
|
---|
48 |
|
---|
49 | \begin{verbatim}
|
---|
50 | import user
|
---|
51 |
|
---|
52 | verbose = bool(getattr(user, "spam_verbose", 0))
|
---|
53 | \end{verbatim}
|
---|
54 |
|
---|
55 | (The three-argument form of \function{getattr()} is used in case
|
---|
56 | the user has not defined \code{spam_verbose} in their
|
---|
57 | \file{.pythonrc.py} file.)
|
---|
58 |
|
---|
59 | Programs with extensive customization needs are better off reading a
|
---|
60 | program-specific customization file.
|
---|
61 |
|
---|
62 | Programs with security or privacy concerns should \emph{not} import
|
---|
63 | this module; a user can easily break into a program by placing
|
---|
64 | arbitrary code in the \file{.pythonrc.py} file.
|
---|
65 |
|
---|
66 | Modules for general use should \emph{not} import this module; it may
|
---|
67 | interfere with the operation of the importing program.
|
---|
68 |
|
---|
69 | \begin{seealso}
|
---|
70 | \seemodule{site}{Site-wide customization mechanism.}
|
---|
71 | \end{seealso}
|
---|