mirror of https://github.com/python/cpython
Added docs for 'user' customization module. Renamed libuser.tex
(which had UserDict/UserList) to libuserdict.tex.
This commit is contained in:
parent
d7ed683a7e
commit
36764b8b0e
|
@ -112,7 +112,8 @@ LIBFILES = lib.tex \
|
|||
libuser.tex libanydbm.tex librandom.tex libsite.tex libwhichdb.tex \
|
||||
libbase64.tex libfnmatch.tex libquopri.tex libzlib.tex libsocksvr.tex \
|
||||
libmailbox.tex libcommands.tex libcmath.tex libni.tex libgzip.tex \
|
||||
libpprint.tex libcode.tex libmimify.tex libre.tex libmacic.tex
|
||||
libpprint.tex libcode.tex libmimify.tex libre.tex libmacic.tex \
|
||||
libuserdict.tex
|
||||
|
||||
# Library document
|
||||
lib.dvi: $(LIBFILES)
|
||||
|
|
|
@ -77,7 +77,7 @@ to Python and how to embed it in other applications.
|
|||
\input{libpython} % Python Services
|
||||
\input{libsys}
|
||||
\input{libtypes2} % types is already taken :-(
|
||||
\input{libuser}
|
||||
\input{libuserdict}
|
||||
\input{liboperator}
|
||||
\input{libtraceback}
|
||||
\input{libpickle}
|
||||
|
@ -90,6 +90,7 @@ to Python and how to embed it in other applications.
|
|||
\input{libpprint}
|
||||
\input{libcode}
|
||||
\input{libsite}
|
||||
\input{libuser}
|
||||
\input{libbltin} % really __builtin__
|
||||
\input{libmain} % really __main__
|
||||
|
||||
|
|
|
@ -77,7 +77,7 @@ to Python and how to embed it in other applications.
|
|||
\input{libpython} % Python Services
|
||||
\input{libsys}
|
||||
\input{libtypes2} % types is already taken :-(
|
||||
\input{libuser}
|
||||
\input{libuserdict}
|
||||
\input{liboperator}
|
||||
\input{libtraceback}
|
||||
\input{libpickle}
|
||||
|
@ -90,6 +90,7 @@ to Python and how to embed it in other applications.
|
|||
\input{libpprint}
|
||||
\input{libcode}
|
||||
\input{libsite}
|
||||
\input{libuser}
|
||||
\input{libbltin} % really __builtin__
|
||||
\input{libmain} % really __main__
|
||||
|
||||
|
|
|
@ -0,0 +1,60 @@
|
|||
\section{Standard Module \sectcode{user}}
|
||||
\label{module-user}
|
||||
\stmodindex{user}
|
||||
\kwindex{.pythonrc.py}
|
||||
|
||||
As a policy, Python doesn't run user-specified code on startup of
|
||||
Python programs. (Only interactive sessions execute the script
|
||||
specified in the \code{PYTHONPATH} environment variable if it exists).
|
||||
|
||||
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
|
||||
|
||||
\bcode\begin{verbatim}
|
||||
import user
|
||||
\end{verbatim}\ecode
|
||||
|
||||
The user module looks for a file \file{.pythonrc.py} in the user's
|
||||
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
|
||||
program that imports the user module, if it wishes. The home
|
||||
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
|
||||
define variables in their \var{.pythonrc.py} file that you test in
|
||||
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.
|
||||
|
||||
For a site-wide customization mechanism, see module \code{site}.
|
|
@ -0,0 +1,60 @@
|
|||
\section{Standard Module \sectcode{user}}
|
||||
\label{module-user}
|
||||
\stmodindex{user}
|
||||
\kwindex{.pythonrc.py}
|
||||
|
||||
As a policy, Python doesn't run user-specified code on startup of
|
||||
Python programs. (Only interactive sessions execute the script
|
||||
specified in the \code{PYTHONPATH} environment variable if it exists).
|
||||
|
||||
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
|
||||
|
||||
\bcode\begin{verbatim}
|
||||
import user
|
||||
\end{verbatim}\ecode
|
||||
|
||||
The user module looks for a file \file{.pythonrc.py} in the user's
|
||||
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
|
||||
program that imports the user module, if it wishes. The home
|
||||
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
|
||||
define variables in their \var{.pythonrc.py} file that you test in
|
||||
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.
|
||||
|
||||
For a site-wide customization mechanism, see module \code{site}.
|
Loading…
Reference in New Issue