--- Python-Docs-2.4/./api/exceptions.tex	2004-06-29 22:52:14.000000000 +0900
+++ Python-Docs-2.5/./api/exceptions.tex	2006-08-14 19:55:19.000000000 +0900
@@ -113,7 +113,7 @@
   exception state.}
 \end{cfuncdesc}
 
-\begin{cfuncdesc}{void}{PyErr_SetString}{PyObject *type, char *message}
+\begin{cfuncdesc}{void}{PyErr_SetString}{PyObject *type, const char *message}
   This is the most common way to set the error indicator.  The first
   argument specifies the exception type; it is normally one of the
   standard exceptions, e.g. \cdata{PyExc_RuntimeError}.  You need not
@@ -135,13 +135,32 @@
   codes, similar to \cfunction{printf()}. The \code{width.precision}
   before a format code is parsed, but the width part is ignored.
 
-  \begin{tableii}{c|l}{character}{Character}{Meaning}
-    \lineii{c}{Character, as an \ctype{int} parameter}
-    \lineii{d}{Number in decimal, as an \ctype{int} parameter}
-    \lineii{x}{Number in hexadecimal, as an \ctype{int} parameter}
-    \lineii{s}{A string, as a \ctype{char *} parameter}
-    \lineii{p}{A hex pointer, as a \ctype{void *} parameter}
-  \end{tableii}
+  % This should be exactly the same as the table in PyString_FromFormat.
+  % One should just refer to the other.
+
+  % The descriptions for %zd and %zu are wrong, but the truth is complicated
+  % because not all compilers support the %z width modifier -- we fake it
+  % when necessary via interpolating PY_FORMAT_SIZE_T.
+
+  % %u, %lu, %zu should have "new in Python 2.5" blurbs.
+
+  \begin{tableiii}{l|l|l}{member}{Format Characters}{Type}{Comment}
+    \lineiii{\%\%}{\emph{n/a}}{The literal \% character.}
+    \lineiii{\%c}{int}{A single character, represented as an C int.}
+    \lineiii{\%d}{int}{Exactly equivalent to \code{printf("\%d")}.}
+    \lineiii{\%u}{unsigned int}{Exactly equivalent to \code{printf("\%u")}.}
+    \lineiii{\%ld}{long}{Exactly equivalent to \code{printf("\%ld")}.}
+    \lineiii{\%lu}{unsigned long}{Exactly equivalent to \code{printf("\%lu")}.}
+    \lineiii{\%zd}{Py_ssize_t}{Exactly equivalent to \code{printf("\%zd")}.}
+    \lineiii{\%zu}{size_t}{Exactly equivalent to \code{printf("\%zu")}.}
+    \lineiii{\%i}{int}{Exactly equivalent to \code{printf("\%i")}.}
+    \lineiii{\%x}{int}{Exactly equivalent to \code{printf("\%x")}.}
+    \lineiii{\%s}{char*}{A null-terminated C character array.}
+    \lineiii{\%p}{void*}{The hex representation of a C pointer.
+	Mostly equivalent to \code{printf("\%p")} except that it is
+	guaranteed to start with the literal \code{0x} regardless of
+	what the platform's \code{printf} yields.}
+  \end{tableiii}
 
   An unrecognized format character causes all the rest of the format
   string to be copied as-is to the result string, and any extra
@@ -184,7 +203,7 @@
 \end{cfuncdesc}
 
 \begin{cfuncdesc}{PyObject*}{PyErr_SetFromErrnoWithFilename}{PyObject *type,
-                                                             char *filename}
+                                                             const char *filename}
   Similar to \cfunction{PyErr_SetFromErrno()}, with the additional
   behavior that if \var{filename} is not \NULL, it is passed to the
   constructor of \var{type} as a third parameter.  In the case of
@@ -217,7 +236,7 @@
 \end{cfuncdesc}
 
 \begin{cfuncdesc}{PyObject*}{PyErr_SetFromWindowsErrWithFilename}{int ierr,
-                                                                char *filename}
+                                                                const char *filename}
   Similar to \cfunction{PyErr_SetFromWindowsErr()}, with the
   additional behavior that if \var{filename} is not \NULL, it is
   passed to the constructor of \exception{WindowsError} as a third
@@ -240,10 +259,14 @@
   argument.  It is mostly for internal use.
 \end{cfuncdesc}
 
-\begin{cfuncdesc}{int}{PyErr_Warn}{PyObject *category, char *message}
+\begin{cfuncdesc}{int}{PyErr_WarnEx}{PyObject *category, char *message, int stacklevel}
   Issue a warning message.  The \var{category} argument is a warning
   category (see below) or \NULL; the \var{message} argument is a
-  message string.
+  message string.  \var{stacklevel} is a positive number giving a
+  number of stack frames; the warning will be issued from the 
+  currently executing line of code in that stack frame.  A \var{stacklevel}
+  of 1 is the function calling \cfunction{PyErr_WarnEx()}, 2 is 
+  the function above that, and so forth.
 
   This function normally prints a warning message to \var{sys.stderr};
   however, it is also possible that the user has specified that
@@ -265,18 +288,30 @@
   names are \samp{PyExc_} followed by the Python exception name.
   These have the type \ctype{PyObject*}; they are all class objects.
   Their names are \cdata{PyExc_Warning}, \cdata{PyExc_UserWarning},
-  \cdata{PyExc_DeprecationWarning}, \cdata{PyExc_SyntaxWarning},
-  \cdata{PyExc_RuntimeWarning}, and \cdata{PyExc_FutureWarning}.
-  \cdata{PyExc_Warning} is a subclass of \cdata{PyExc_Exception}; the
-  other warning categories are subclasses of \cdata{PyExc_Warning}.
+  \cdata{PyExc_UnicodeWarning}, \cdata{PyExc_DeprecationWarning},
+  \cdata{PyExc_SyntaxWarning}, \cdata{PyExc_RuntimeWarning}, and
+  \cdata{PyExc_FutureWarning}.  \cdata{PyExc_Warning} is a subclass of
+  \cdata{PyExc_Exception}; the other warning categories are subclasses
+  of \cdata{PyExc_Warning}.
 
   For information about warning control, see the documentation for the
   \module{warnings} module and the \programopt{-W} option in the
   command line documentation.  There is no C API for warning control.
 \end{cfuncdesc}
 
-\begin{cfuncdesc}{int}{PyErr_WarnExplicit}{PyObject *category, char *message,
-                char *filename, int lineno, char *module, PyObject *registry}
+\begin{cfuncdesc}{int}{PyErr_Warn}{PyObject *category, char *message}
+  Issue a warning message.  The \var{category} argument is a warning
+  category (see below) or \NULL; the \var{message} argument is a
+  message string.  The warning will appear to be issued from the function
+  calling \cfunction{PyErr_Warn()}, equivalent to calling
+  \cfunction{PyErr_WarnEx()} with a \var{stacklevel} of 1.
+  
+  Deprecated; use \cfunction{PyErr_WarnEx()} instead.
+\end{cfuncdesc}
+
+\begin{cfuncdesc}{int}{PyErr_WarnExplicit}{PyObject *category,
+                const char *message, const char *filename, int lineno,
+                const char *module, PyObject *registry}
   Issue a warning message with explicit control over all warning
   attributes.  This is a straightforward wrapper around the Python
   function \function{warnings.warn_explicit()}, see there for more
@@ -316,12 +351,14 @@
   The \var{name} argument must be the name of the new exception, a C
   string of the form \code{module.class}.  The \var{base} and
   \var{dict} arguments are normally \NULL.  This creates a class
-  object derived from the root for all exceptions, the built-in name
-  \exception{Exception} (accessible in C as \cdata{PyExc_Exception}).
+  object derived from \exception{Exception} (accessible in C as
+  \cdata{PyExc_Exception}).
+
   The \member{__module__} attribute of the new class is set to the
   first part (up to the last dot) of the \var{name} argument, and the
   class name is set to the last part (after the last dot).  The
-  \var{base} argument can be used to specify an alternate base class.
+  \var{base} argument can be used to specify alternate base classes;
+  it can either be only one class or a tuple of classes.
   The \var{dict} argument can be used to specify a dictionary of class
   variables and methods.
 \end{cfuncdesc}
@@ -345,6 +382,7 @@
 completeness, here are all the variables:
 
 \begin{tableiii}{l|l|c}{cdata}{C Name}{Python Name}{Notes}
+  \lineiii{PyExc_BaseException\ttindex{PyExc_BaseException}}{\exception{BaseException}}{(1), (4)}
   \lineiii{PyExc_Exception\ttindex{PyExc_Exception}}{\exception{Exception}}{(1)}
   \lineiii{PyExc_StandardError\ttindex{PyExc_StandardError}}{\exception{StandardError}}{(1)}
   \lineiii{PyExc_ArithmeticError\ttindex{PyExc_ArithmeticError}}{\exception{ArithmeticError}}{(1)}
@@ -387,15 +425,18 @@
 \item[(3)]
   Only defined on Windows; protect code that uses this by testing that
   the preprocessor macro \code{MS_WINDOWS} is defined.
+
+\item[(4)]
+  \versionadded{2.5}
 \end{description}
 
 
 \section{Deprecation of String Exceptions}
 
 All exceptions built into Python or provided in the standard library
-are derived from \exception{Exception}.
-\withsubitem{(built-in exception)}{\ttindex{Exception}}
+are derived from \exception{BaseException}.
+\withsubitem{(built-in exception)}{\ttindex{BaseException}}
 
 String exceptions are still supported in the interpreter to allow
-existing code to run unmodified, but this will also change in a future 
+existing code to run unmodified, but this will also change in a future
 release.
