traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Done with the "New in 1.4" chapter.

This commit is contained in:
Guido van Rossum 1996-10-24 22:12:48 +00:00
parent b0259bc3ad
commit 3a26dd88af
2 changed files with 278 additions and 150 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

214
Doc/tut.tex
View File

@ -28,8 +28,8 @@ language for highly customizable C applications such as editors or
window managers. window managers.
Python is available for various operating systems, amongst which Python is available for various operating systems, amongst which
several flavors of {\UNIX}, Amoeba, the Apple Macintosh O.S., several flavors of {\UNIX}, the Apple Macintosh, MS-DOS, Windows
and MS-DOS. (3.1(1), '95 and NT flavors), OS/2, and others.
This tutorial introduces the reader informally to the basic concepts This tutorial introduces the reader informally to the basic concepts
and features of the Python language and system. It helps to have a and features of the Python language and system. It helps to have a
@ -55,6 +55,23 @@ a more formal definition of the language.
\chapter{Whetting Your Appetite} \chapter{Whetting Your Appetite}
\section{Disclaimer}
Now that there are several books out on Python, this tutorial has lost
its role as the only introduction to Python for most new users. It
takes time to keep a document like this up to date in the face of
additions to the language, and I simply don't have enough time to do a
good job. Therefore, this version of the tutorial is almost unchanged
since the previous release. This doesn't mean that the tutorial is
out of date --- all the examples still work exactly as before. There
are simply some new areas of the language that aren't covered.
To make up for this, there are some chapters at the end cover
important changes in recent Python releases, and these are up to date
with the current release.
\section{Introduction}
If you ever wrote a large shell script, you probably know this If you ever wrote a large shell script, you probably know this
feeling: you'd love to add yet another feature, but it's already so feeling: you'd love to add yet another feature, but it's already so
slow, and so big, and so complicated; or the feature involves a system slow, and so big, and so complicated; or the feature involves a system
@ -2620,7 +2637,7 @@ object of which the method is an instance, and \verb\m.im_func\ is the
function object corresponding to the method. function object corresponding to the method.
\chapter{Recent Additions} \chapter{Recent Additions as of Release 1.1}
Python is an evolving language. Since this tutorial was last Python is an evolving language. Since this tutorial was last
thoroughly revised, several new features have been added to the thoroughly revised, several new features have been added to the
@ -3879,6 +3896,8 @@ changes that only affect C programmers or the build and installation
process are not described in this chapter (the new installation process are not described in this chapter (the new installation
lay-out is explained below under \code{sys.prefix} though). lay-out is explained below under \code{sys.prefix} though).
\section{Language Changes}
\begin{itemize} \begin{itemize}
\item \item
@ -3941,7 +3960,7 @@ slice is used, i.e. \code{x[lo:hi]}, with possible omission of
\begin{verbatim} \begin{verbatim}
x[0:10:2] -> slice(0, 10, 2) x[0:10:2] -> slice(0, 10, 2)
x[:2:] -> slice(None, 2, None) x[:2:] -> slice(None, 2, None)
x[::-1] -> slice(None, None, -1) x[::-1] -> slice(None, None, -1)
x[::] -> slice(None, None, None) x[::] -> slice(None, None, None)
x[1, 2:3] -> (1, slice(2, 3, None)) x[1, 2:3] -> (1, slice(2, 3, None))
x[1:2, 3:4] -> (slice(1, 2, None), slice(3, 4, None)) x[1:2, 3:4] -> (slice(1, 2, None), slice(3, 4, None))
@ -3956,7 +3975,8 @@ The \code{access} statement is now truly gone; \code{access} is no
longer a reserved word. This saves a few cycles here and there. longer a reserved word. This saves a few cycles here and there.
\item \item
Name mangling. There is now limited support for class-private Private variables through name mangling.
There is now limited support for class-private
identifiers. Any identifier of the form \code{__spam} (at least two identifiers. Any identifier of the form \code{__spam} (at least two
leading underscores, at most one trailing underscore) is now textually leading underscores, at most one trailing underscore) is now textually
replaced with \code{_classname__spam}, where \code{classname} is the replaced with \code{_classname__spam}, where \code{classname} is the
@ -3976,9 +3996,9 @@ instance variables by code outside the class. Note that the mangling
rules are designed mostly to avoid accidents; it still is possible for rules are designed mostly to avoid accidents; it still is possible for
a determined soul to access or modify a variable that is considered a determined soul to access or modify a variable that is considered
private. This can even be useful, e.g. for the debugger, and that's private. This can even be useful, e.g. for the debugger, and that's
one reason why this loophole is not closed. (Buglet: accidental one reason why this loophole is not closed. (Buglet: derivation of a
derivation of a class with the same name as the base class makes class with the same name as the base class makes use of private
accidental use of private variables of the base class possible.) variables of the base class possible.)
Notice that code passed to \code{exec}, \code{eval()} or Notice that code passed to \code{exec}, \code{eval()} or
\code{evalfile()} does not consider the classname of the invoking \code{evalfile()} does not consider the classname of the invoking
@ -4008,6 +4028,31 @@ class VirtualAttributes:
self.__vdict[name] = value self.__vdict[name] = value
\end{verbatim} \end{verbatim}
{\em Warning: this is an experimental feature.} To avoid all
potential problems, refrain from using identifiers starting with
double underscore except for predefined uses like \code{__init__}. To
use private names while maintaining future compatibility: refrain from
using the same private name in classes related via subclassing; avoid
explicit (manual) mangling/unmangling; and assume that at some point
in the future, leading double underscore will revert to being just a
naming convention. Discussion on extensive compile-time declarations
are currently underway, and it is impossible to predict what solution
will eventually be chosen for private names. Double leading
underscore is still a candidate, of course --- just not the only one.
It is placed in the distribution in the belief that it is useful, and
so that widespread experience with its use can be gained. It will not
be removed without providing a better solution and a migration path.
\end{itemize}
\section{Run-time Changes}
\begin{itemize}
\item
New built-in function \code{list()} converts any sequence to a new list.
Note that when the argument is a list, the return value is a fresh
copy, similar to what would be returned by \code{a[:]}.
\item \item
Improved syntax error message. Syntax errors detected by the code Improved syntax error message. Syntax errors detected by the code
@ -4026,17 +4071,27 @@ Exceptions in \code{__del__} methods. When a \code{__del__} method
raises an exception, a warning is written to \code{sys.stderr} and the raises an exception, a warning is written to \code{sys.stderr} and the
exception is ignored. Formerly, such exceptions were ignored without exception is ignored. Formerly, such exceptions were ignored without
warning. (Propagating the exception is not an option since it it is warning. (Propagating the exception is not an option since it it is
invoked from an object finalizer, which cannot invoked from an object finalizer, which cannot return any kind of
) (Buglet: The new behavior, while needed in order to debug failing status or error.) (Buglet: The new behavior, while needed in order to
\code{__del__} methods, is occasionally annoying, because if affects debug failing \code{__del__} methods, is occasionally annoying,
the program's standard error stream. It honors assignments to because if affects the program's standard error stream. It honors
\code{sys.stderr}, so it can be redirected from within a program if assignments to \code{sys.stderr}, so it can be redirected from within
desired.) a program if desired.)
\item \item
New built-in function \code{list()} converts any sequence to a new list. You can now discover from which file (if any) a module was loaded by
Note that when the argument is a list, the return value is a fresh inspecting its \code{__file__} attribute. This attribute is not
copy, similar to what would be returned by \code{a[:]}. present for built-in or frozen modules. It points to the shared
library file for dynamically loaded modules. (Buglet: this may be a
relative path and is stored in the \code{.pyc} file on compilation.
If you manipulate the current directory with \code{os.chdir()} or move
\code{.pyc} files around, the value may be incorrect.)
\end{itemize}
\section{New or Updated Modules}
\begin{itemize}
\item \item
New built-in module \code{operator}. While undocumented, the concept New built-in module \code{operator}. While undocumented, the concept
@ -4084,34 +4139,40 @@ delimiters as well as the words in the resulting list). The optional
\item \item
Module files \code{pdb.py} and \code{profile.py} can now be invoked as Module files \code{pdb.py} and \code{profile.py} can now be invoked as
scripts to debug c.q. profile other scripts easily. scripts to debug c.q. profile other scripts easily. For example:
\code{python /usr/local/lib/python1.4/profile.py myscript.py}
\item \item
The \code{os} module now supports the \code{putenv()} function on The \code{os} module now supports the \code{putenv()} function on
systems where it is provided in the C library (Windows NT and most systems where it is provided in the C library (Windows NT and most
Unix versions). The call \code{os.putenv('PATH', '/bin:/usr/bin')} Unix versions). For example, \code{os.putenv('PATH',
sets the environment variable \code{PATH} to the string '/bin:/usr/bin')} sets the environment variable \code{PATH} to the
\code{'/bin:/usr/bin'}. Such changes to the environment affect string \code{'/bin:/usr/bin'}. Such changes to the environment affect
subprocesses started with \code{os.system()}, \code{os.popen()} or subprocesses started with \code{os.system()}, \code{os.popen()} or
\code{os.fork()} and \code{os.execv()}. When \code{putenv()} is \code{os.fork()} and \code{os.execv()}. When \code{putenv()} is
supported, assignments to items in \code{os.environ} are automatically supported, assignments to items in \code{os.environ} are automatically
translated into corresponding calls to \code{os.putenv()}; however, translated into corresponding calls to \code{os.putenv()}; however,
calls to \code{os.putenv()} don't update \code{os.environ}, so it is calls to \code{os.putenv()} don't update \code{os.environ}, so it is
actually preferable to assign to items of \code{os.environ}. For this actually preferable to assign to items of \code{os.environ}. For this
purpose, the type of \code{os.environ} is changed to a subclass of purpose, the type of \code{os.environ} is changed to a subclass of
\code{UserDict.UserDict} when \code{os.putenv()} is supported. \code{UserDict.UserDict} when \code{os.putenv()} is supported.
(Buglet: \code{os.execve()} still requires a real dictionary.) (Buglet: \code{os.execve()} still requires a real dictionary, so it
won't accept \code{os.environ} as its third argument. However, you
can now use \code{os.execv()} and it will use your changes to
\code{os.environ}!.)
\item \item
New functions in the os module: mkfifo, plock, remove (== unlink), More new functions in the \code{os} module: \code{mkfifo},
and ftruncate. More functions are also available under NT. XXX \code{plock}, \code{remove} (== \code{unlink}), and \code{ftruncate}.
See the Unix manual (section 2, system calls) for these function.
More functions are also available under NT.
\item \item
New functions in the fcntl module: \code{lockf()} and \code{flock()} New functions in the fcntl module: \code{lockf()} and \code{flock()}
(don't ask \code{:-)}). See the Library Reference Manual. (don't ask \code{:-)}). See the Library Reference Manual.
\item \item
The first item of the module search path, \code{sys.path}, is the The first item of the module search path, \code{sys.path[0]}, is the
directory containing the script that was used to invoke the Python directory containing the script that was used to invoke the Python
interpreter. If the script directory is not available (e.g. if the interpreter. If the script directory is not available (e.g. if the
interpreter is invoked interactively or if the script is read from interpreter is invoked interactively or if the script is read from
@ -4119,56 +4180,59 @@ standard input), \code{sys.path[0]} is the empty string, which directs
Python to search modules in the current directory first. Notice that Python to search modules in the current directory first. Notice that
the script directory is inserted {\em before} the entries inserted as the script directory is inserted {\em before} the entries inserted as
a result of \code{\$PYTHONPATH}. There is no longer an entry for the a result of \code{\$PYTHONPATH}. There is no longer an entry for the
current directory later in the path (unless explicitly set by current directory later in the path (unless explicitly set in
\code{\$PYTHONPATH}). \code{\$PYTHONPATH} or overridden at build time).
\end{itemize}
\section{Configuration and Installation}
\begin{itemize}
\item \item
Some more configuration information is now available to Python More configuration information is now available to Python programs.
programs. The variable \code{sys.prefix} gives the site-specific The variable \code{sys.prefix} gives the site-specific directory
directory prefix where the platform independent Python files are prefix where the platform independent Python files are installed; by
installed; by default, this is the string \code{"/usr/local"}. The default, this is the string \code{"/usr/local"}. This can be set at
main collection of Python library modules is installed in the build time with the \code{--prefix} argument to the \code{configure}
directory \code{sys.prefix+"/lib/python"+sys.version[:3]} while the script. The main collection of Python library modules is installed in
platform independent header files (all except \code{config.h}) are the directory \code{sys.prefix+"/lib/python1.4"} while the platform
stored in \code{sys.prefix+"/include/python"+sys.version[:3]}. independent header files (all except \code{config.h}) are stored in
\code{sys.prefix+"/include/python1.4"}.
Similarly, the variable \code{sys.exec_prefix} gives the site-specific Similarly, the variable \code{sys.exec_prefix} gives the site-specific
directory prefix where the platform {\em de}pendent Python files are directory prefix where the platform {\em de}pendent Python files are
installed; by default, this is also \code{"/usr/local"}. installed; by default, this is also \code{"/usr/local"}. This can be
Specifically, all configuration files (e.g. the \code{config.h} set at build time with the \code{--exec-prefix} argument to the
header file) are installed in the directory \code{configure} script. Specifically, all configuration files
\code{sys.exec_prefix+"/lib/python"+sys.version[:3]+"/config"}, (e.g. the \code{config.h} header file) are installed in the directory
and shared library modules are installed in \code{sys.exec_prefix+"/lib/python1.4/config"}, and shared library
\code{sys.exec_prefix+"/lib/python"+sys.version[:3]+"/sharedmodules"}. modules are installed in
\code{sys.exec_prefix+"/lib/python1.4/sharedmodules"}.
Include files are at \code{sys.prefix+"/include/python1.4"}.
It is not yet decided what the most portable way is to come up with
the version number used in these pathnames. For compatibility with
the 1.4beta releases, sys.version[:3] can be used.
On non-Unix systems, these variables are meaningless. On non-Unix systems, these variables are meaningless.
\item \item
You can now discover from which file (if any) a module was loaded by While sites are strongly discouraged from modifying the standard
inspecting its \code{__file__} attribute. This attribute is not Python library (like adding site-specific modules or functions), there
present for built-in or frozen modules. It points to the shared is now a standard way to invoke site-specific features. The standard
library file for dynamically loaded modules. (Buglet: this may be a module \code{site}, when imported, appends two site-specific
relative path and is stored in the \code{.pyc} file on compilation. directories to the end of \code{sys.path}:
If you manipulate the current directory with \code{os.chdir()} or move \code{\$prefix/lib/site-python} and
\code{.pyc} files around, the value may be incorrect.) \code{\$exec_prefix/lib/site-python}, where \code{\$prefix} and
\code{\$exec_prefix} are the directories \code{sys.prefix} and
\item
While sites are strongly discouraged from modifying the standard
Python library (e.g. by adding site-specific modules or functions),
there is now a standard way to invoke site-specific features. The
standard module \code{site}, when imported, appends two site-specific
directories to the end of \code{sys.path}:
\code{\$prefix/lib/site-python} and
\code{\$exec_prefix/lib/site-python}, where \code{\$prefix} and
\code{\$exec_prefix} are the directories \code{sys.prefix} and
\code{sys.exec_prefix} mentioned above. \code{sys.exec_prefix} mentioned above.
\item After this path manipulation has been performed, an attempt is made to
There's more. As I said, see \code{Misc/NEWS}... import the module \code{sitecustomize}. Any \code{ImportError}
exception raised by this attempt is silently ignored.
\end{itemize} \end{itemize}
\end{document} \end{document}

214
Doc/tut/tut.tex
View File

@ -28,8 +28,8 @@ language for highly customizable C applications such as editors or
window managers. window managers.
Python is available for various operating systems, amongst which Python is available for various operating systems, amongst which
several flavors of {\UNIX}, Amoeba, the Apple Macintosh O.S., several flavors of {\UNIX}, the Apple Macintosh, MS-DOS, Windows
and MS-DOS. (3.1(1), '95 and NT flavors), OS/2, and others.
This tutorial introduces the reader informally to the basic concepts This tutorial introduces the reader informally to the basic concepts
and features of the Python language and system. It helps to have a and features of the Python language and system. It helps to have a
@ -55,6 +55,23 @@ a more formal definition of the language.
\chapter{Whetting Your Appetite} \chapter{Whetting Your Appetite}
\section{Disclaimer}
Now that there are several books out on Python, this tutorial has lost
its role as the only introduction to Python for most new users. It
takes time to keep a document like this up to date in the face of
additions to the language, and I simply don't have enough time to do a
good job. Therefore, this version of the tutorial is almost unchanged
since the previous release. This doesn't mean that the tutorial is
out of date --- all the examples still work exactly as before. There
are simply some new areas of the language that aren't covered.
To make up for this, there are some chapters at the end cover
important changes in recent Python releases, and these are up to date
with the current release.
\section{Introduction}
If you ever wrote a large shell script, you probably know this If you ever wrote a large shell script, you probably know this
feeling: you'd love to add yet another feature, but it's already so feeling: you'd love to add yet another feature, but it's already so
slow, and so big, and so complicated; or the feature involves a system slow, and so big, and so complicated; or the feature involves a system
@ -2620,7 +2637,7 @@ object of which the method is an instance, and \verb\m.im_func\ is the
function object corresponding to the method. function object corresponding to the method.
\chapter{Recent Additions} \chapter{Recent Additions as of Release 1.1}
Python is an evolving language. Since this tutorial was last Python is an evolving language. Since this tutorial was last
thoroughly revised, several new features have been added to the thoroughly revised, several new features have been added to the
@ -3879,6 +3896,8 @@ changes that only affect C programmers or the build and installation
process are not described in this chapter (the new installation process are not described in this chapter (the new installation
lay-out is explained below under \code{sys.prefix} though). lay-out is explained below under \code{sys.prefix} though).
\section{Language Changes}
\begin{itemize} \begin{itemize}
\item \item
@ -3941,7 +3960,7 @@ slice is used, i.e. \code{x[lo:hi]}, with possible omission of
\begin{verbatim} \begin{verbatim}
x[0:10:2] -> slice(0, 10, 2) x[0:10:2] -> slice(0, 10, 2)
x[:2:] -> slice(None, 2, None) x[:2:] -> slice(None, 2, None)
x[::-1] -> slice(None, None, -1) x[::-1] -> slice(None, None, -1)
x[::] -> slice(None, None, None) x[::] -> slice(None, None, None)
x[1, 2:3] -> (1, slice(2, 3, None)) x[1, 2:3] -> (1, slice(2, 3, None))
x[1:2, 3:4] -> (slice(1, 2, None), slice(3, 4, None)) x[1:2, 3:4] -> (slice(1, 2, None), slice(3, 4, None))
@ -3956,7 +3975,8 @@ The \code{access} statement is now truly gone; \code{access} is no
longer a reserved word. This saves a few cycles here and there. longer a reserved word. This saves a few cycles here and there.
\item \item
Name mangling. There is now limited support for class-private Private variables through name mangling.
There is now limited support for class-private
identifiers. Any identifier of the form \code{__spam} (at least two identifiers. Any identifier of the form \code{__spam} (at least two
leading underscores, at most one trailing underscore) is now textually leading underscores, at most one trailing underscore) is now textually
replaced with \code{_classname__spam}, where \code{classname} is the replaced with \code{_classname__spam}, where \code{classname} is the
@ -3976,9 +3996,9 @@ instance variables by code outside the class. Note that the mangling
rules are designed mostly to avoid accidents; it still is possible for rules are designed mostly to avoid accidents; it still is possible for
a determined soul to access or modify a variable that is considered a determined soul to access or modify a variable that is considered
private. This can even be useful, e.g. for the debugger, and that's private. This can even be useful, e.g. for the debugger, and that's
one reason why this loophole is not closed. (Buglet: accidental one reason why this loophole is not closed. (Buglet: derivation of a
derivation of a class with the same name as the base class makes class with the same name as the base class makes use of private
accidental use of private variables of the base class possible.) variables of the base class possible.)
Notice that code passed to \code{exec}, \code{eval()} or Notice that code passed to \code{exec}, \code{eval()} or
\code{evalfile()} does not consider the classname of the invoking \code{evalfile()} does not consider the classname of the invoking
@ -4008,6 +4028,31 @@ class VirtualAttributes:
self.__vdict[name] = value self.__vdict[name] = value
\end{verbatim} \end{verbatim}
{\em Warning: this is an experimental feature.} To avoid all
potential problems, refrain from using identifiers starting with
double underscore except for predefined uses like \code{__init__}. To
use private names while maintaining future compatibility: refrain from
using the same private name in classes related via subclassing; avoid
explicit (manual) mangling/unmangling; and assume that at some point
in the future, leading double underscore will revert to being just a
naming convention. Discussion on extensive compile-time declarations
are currently underway, and it is impossible to predict what solution
will eventually be chosen for private names. Double leading
underscore is still a candidate, of course --- just not the only one.
It is placed in the distribution in the belief that it is useful, and
so that widespread experience with its use can be gained. It will not
be removed without providing a better solution and a migration path.
\end{itemize}
\section{Run-time Changes}
\begin{itemize}
\item
New built-in function \code{list()} converts any sequence to a new list.
Note that when the argument is a list, the return value is a fresh
copy, similar to what would be returned by \code{a[:]}.
\item \item
Improved syntax error message. Syntax errors detected by the code Improved syntax error message. Syntax errors detected by the code
@ -4026,17 +4071,27 @@ Exceptions in \code{__del__} methods. When a \code{__del__} method
raises an exception, a warning is written to \code{sys.stderr} and the raises an exception, a warning is written to \code{sys.stderr} and the
exception is ignored. Formerly, such exceptions were ignored without exception is ignored. Formerly, such exceptions were ignored without
warning. (Propagating the exception is not an option since it it is warning. (Propagating the exception is not an option since it it is
invoked from an object finalizer, which cannot invoked from an object finalizer, which cannot return any kind of
) (Buglet: The new behavior, while needed in order to debug failing status or error.) (Buglet: The new behavior, while needed in order to
\code{__del__} methods, is occasionally annoying, because if affects debug failing \code{__del__} methods, is occasionally annoying,
the program's standard error stream. It honors assignments to because if affects the program's standard error stream. It honors
\code{sys.stderr}, so it can be redirected from within a program if assignments to \code{sys.stderr}, so it can be redirected from within
desired.) a program if desired.)
\item \item
New built-in function \code{list()} converts any sequence to a new list. You can now discover from which file (if any) a module was loaded by
Note that when the argument is a list, the return value is a fresh inspecting its \code{__file__} attribute. This attribute is not
copy, similar to what would be returned by \code{a[:]}. present for built-in or frozen modules. It points to the shared
library file for dynamically loaded modules. (Buglet: this may be a
relative path and is stored in the \code{.pyc} file on compilation.
If you manipulate the current directory with \code{os.chdir()} or move
\code{.pyc} files around, the value may be incorrect.)
\end{itemize}
\section{New or Updated Modules}
\begin{itemize}
\item \item
New built-in module \code{operator}. While undocumented, the concept New built-in module \code{operator}. While undocumented, the concept
@ -4084,34 +4139,40 @@ delimiters as well as the words in the resulting list). The optional
\item \item
Module files \code{pdb.py} and \code{profile.py} can now be invoked as Module files \code{pdb.py} and \code{profile.py} can now be invoked as
scripts to debug c.q. profile other scripts easily. scripts to debug c.q. profile other scripts easily. For example:
\code{python /usr/local/lib/python1.4/profile.py myscript.py}
\item \item
The \code{os} module now supports the \code{putenv()} function on The \code{os} module now supports the \code{putenv()} function on
systems where it is provided in the C library (Windows NT and most systems where it is provided in the C library (Windows NT and most
Unix versions). The call \code{os.putenv('PATH', '/bin:/usr/bin')} Unix versions). For example, \code{os.putenv('PATH',
sets the environment variable \code{PATH} to the string '/bin:/usr/bin')} sets the environment variable \code{PATH} to the
\code{'/bin:/usr/bin'}. Such changes to the environment affect string \code{'/bin:/usr/bin'}. Such changes to the environment affect
subprocesses started with \code{os.system()}, \code{os.popen()} or subprocesses started with \code{os.system()}, \code{os.popen()} or
\code{os.fork()} and \code{os.execv()}. When \code{putenv()} is \code{os.fork()} and \code{os.execv()}. When \code{putenv()} is
supported, assignments to items in \code{os.environ} are automatically supported, assignments to items in \code{os.environ} are automatically
translated into corresponding calls to \code{os.putenv()}; however, translated into corresponding calls to \code{os.putenv()}; however,
calls to \code{os.putenv()} don't update \code{os.environ}, so it is calls to \code{os.putenv()} don't update \code{os.environ}, so it is
actually preferable to assign to items of \code{os.environ}. For this actually preferable to assign to items of \code{os.environ}. For this
purpose, the type of \code{os.environ} is changed to a subclass of purpose, the type of \code{os.environ} is changed to a subclass of
\code{UserDict.UserDict} when \code{os.putenv()} is supported. \code{UserDict.UserDict} when \code{os.putenv()} is supported.
(Buglet: \code{os.execve()} still requires a real dictionary.) (Buglet: \code{os.execve()} still requires a real dictionary, so it
won't accept \code{os.environ} as its third argument. However, you
can now use \code{os.execv()} and it will use your changes to
\code{os.environ}!.)
\item \item
New functions in the os module: mkfifo, plock, remove (== unlink), More new functions in the \code{os} module: \code{mkfifo},
and ftruncate. More functions are also available under NT. XXX \code{plock}, \code{remove} (== \code{unlink}), and \code{ftruncate}.
See the Unix manual (section 2, system calls) for these function.
More functions are also available under NT.
\item \item
New functions in the fcntl module: \code{lockf()} and \code{flock()} New functions in the fcntl module: \code{lockf()} and \code{flock()}
(don't ask \code{:-)}). See the Library Reference Manual. (don't ask \code{:-)}). See the Library Reference Manual.
\item \item
The first item of the module search path, \code{sys.path}, is the The first item of the module search path, \code{sys.path[0]}, is the
directory containing the script that was used to invoke the Python directory containing the script that was used to invoke the Python
interpreter. If the script directory is not available (e.g. if the interpreter. If the script directory is not available (e.g. if the
interpreter is invoked interactively or if the script is read from interpreter is invoked interactively or if the script is read from
@ -4119,56 +4180,59 @@ standard input), \code{sys.path[0]} is the empty string, which directs
Python to search modules in the current directory first. Notice that Python to search modules in the current directory first. Notice that
the script directory is inserted {\em before} the entries inserted as the script directory is inserted {\em before} the entries inserted as
a result of \code{\$PYTHONPATH}. There is no longer an entry for the a result of \code{\$PYTHONPATH}. There is no longer an entry for the
current directory later in the path (unless explicitly set by current directory later in the path (unless explicitly set in
\code{\$PYTHONPATH}). \code{\$PYTHONPATH} or overridden at build time).
\end{itemize}
\section{Configuration and Installation}
\begin{itemize}
\item \item
Some more configuration information is now available to Python More configuration information is now available to Python programs.
programs. The variable \code{sys.prefix} gives the site-specific The variable \code{sys.prefix} gives the site-specific directory
directory prefix where the platform independent Python files are prefix where the platform independent Python files are installed; by
installed; by default, this is the string \code{"/usr/local"}. The default, this is the string \code{"/usr/local"}. This can be set at
main collection of Python library modules is installed in the build time with the \code{--prefix} argument to the \code{configure}
directory \code{sys.prefix+"/lib/python"+sys.version[:3]} while the script. The main collection of Python library modules is installed in
platform independent header files (all except \code{config.h}) are the directory \code{sys.prefix+"/lib/python1.4"} while the platform
stored in \code{sys.prefix+"/include/python"+sys.version[:3]}. independent header files (all except \code{config.h}) are stored in
\code{sys.prefix+"/include/python1.4"}.
Similarly, the variable \code{sys.exec_prefix} gives the site-specific Similarly, the variable \code{sys.exec_prefix} gives the site-specific
directory prefix where the platform {\em de}pendent Python files are directory prefix where the platform {\em de}pendent Python files are
installed; by default, this is also \code{"/usr/local"}. installed; by default, this is also \code{"/usr/local"}. This can be
Specifically, all configuration files (e.g. the \code{config.h} set at build time with the \code{--exec-prefix} argument to the
header file) are installed in the directory \code{configure} script. Specifically, all configuration files
\code{sys.exec_prefix+"/lib/python"+sys.version[:3]+"/config"}, (e.g. the \code{config.h} header file) are installed in the directory
and shared library modules are installed in \code{sys.exec_prefix+"/lib/python1.4/config"}, and shared library
\code{sys.exec_prefix+"/lib/python"+sys.version[:3]+"/sharedmodules"}. modules are installed in
\code{sys.exec_prefix+"/lib/python1.4/sharedmodules"}.
Include files are at \code{sys.prefix+"/include/python1.4"}.
It is not yet decided what the most portable way is to come up with
the version number used in these pathnames. For compatibility with
the 1.4beta releases, sys.version[:3] can be used.
On non-Unix systems, these variables are meaningless. On non-Unix systems, these variables are meaningless.
\item \item
You can now discover from which file (if any) a module was loaded by While sites are strongly discouraged from modifying the standard
inspecting its \code{__file__} attribute. This attribute is not Python library (like adding site-specific modules or functions), there
present for built-in or frozen modules. It points to the shared is now a standard way to invoke site-specific features. The standard
library file for dynamically loaded modules. (Buglet: this may be a module \code{site}, when imported, appends two site-specific
relative path and is stored in the \code{.pyc} file on compilation. directories to the end of \code{sys.path}:
If you manipulate the current directory with \code{os.chdir()} or move \code{\$prefix/lib/site-python} and
\code{.pyc} files around, the value may be incorrect.) \code{\$exec_prefix/lib/site-python}, where \code{\$prefix} and
\code{\$exec_prefix} are the directories \code{sys.prefix} and
\item
While sites are strongly discouraged from modifying the standard
Python library (e.g. by adding site-specific modules or functions),
there is now a standard way to invoke site-specific features. The
standard module \code{site}, when imported, appends two site-specific
directories to the end of \code{sys.path}:
\code{\$prefix/lib/site-python} and
\code{\$exec_prefix/lib/site-python}, where \code{\$prefix} and
\code{\$exec_prefix} are the directories \code{sys.prefix} and
\code{sys.exec_prefix} mentioned above. \code{sys.exec_prefix} mentioned above.
\item After this path manipulation has been performed, an attempt is made to
There's more. As I said, see \code{Misc/NEWS}... import the module \code{sitecustomize}. Any \code{ImportError}
exception raised by this attempt is silently ignored.
\end{itemize} \end{itemize}
\end{document} \end{document}