mirror of
https://github.com/python/cpython.git
synced 2025-12-04 16:43:27 +00:00
lots of markup nits, most commonly Unix/unix --> \UNIX
This commit is contained in:
parent
da9face1fe
commit
e0d4aecfc2
20 changed files with 49 additions and 49 deletions
|
|
@ -597,11 +597,11 @@ described in the remainder of this section.
|
||||||
|
|
||||||
Compiling the interpreter with the \csimplemacro{Py_DEBUG} macro
|
Compiling the interpreter with the \csimplemacro{Py_DEBUG} macro
|
||||||
defined produces what is generally meant by "a debug build" of Python.
|
defined produces what is generally meant by "a debug build" of Python.
|
||||||
\csimplemacro{Py_DEBUG} is enabled in the Unix build by adding
|
\csimplemacro{Py_DEBUG} is enabled in the \UNIX{} build by adding
|
||||||
\longprogramopt{with-pydebug} to the \file{configure} command. It is also
|
\longprogramopt{with-pydebug} to the \file{configure} command. It is also
|
||||||
implied by the presence of the not-Python-specific
|
implied by the presence of the not-Python-specific
|
||||||
\csimplemacro{_DEBUG} macro. When \csimplemacro{Py_DEBUG} is enabled
|
\csimplemacro{_DEBUG} macro. When \csimplemacro{Py_DEBUG} is enabled
|
||||||
in the Unix build, compiler optimization is disabled.
|
in the \UNIX{} build, compiler optimization is disabled.
|
||||||
|
|
||||||
In addition to the reference count debugging described below, the
|
In addition to the reference count debugging described below, the
|
||||||
following extra checks are performed:
|
following extra checks are performed:
|
||||||
|
|
|
||||||
10
Doc/dist/dist.tex
vendored
10
Doc/dist/dist.tex
vendored
|
|
@ -530,7 +530,7 @@ If you need to include header files from some other Python extension,
|
||||||
you can take advantage of the fact that header files are installed in a
|
you can take advantage of the fact that header files are installed in a
|
||||||
consistent way by the Distutils \command{install\_header} command. For
|
consistent way by the Distutils \command{install\_header} command. For
|
||||||
example, the Numerical Python header files are installed (on a standard
|
example, the Numerical Python header files are installed (on a standard
|
||||||
Unix installation) to \file{/usr/local/include/python1.5/Numerical}.
|
\UNIX{} installation) to \file{/usr/local/include/python1.5/Numerical}.
|
||||||
(The exact location will differ according to your platform and Python
|
(The exact location will differ according to your platform and Python
|
||||||
installation.) Since the Python include
|
installation.) Since the Python include
|
||||||
directory---\file{/usr/local/include/python1.5} in this case---is always
|
directory---\file{/usr/local/include/python1.5} in this case---is always
|
||||||
|
|
@ -2317,7 +2317,7 @@ constructor
|
||||||
\lineiii{name}{the full name of the extension, including any packages
|
\lineiii{name}{the full name of the extension, including any packages
|
||||||
--- ie. \emph{not} a filename or pathname, but Python dotted name}{string}
|
--- ie. \emph{not} a filename or pathname, but Python dotted name}{string}
|
||||||
\lineiii{sources}{list of source filenames, relative to the distribution
|
\lineiii{sources}{list of source filenames, relative to the distribution
|
||||||
root (where the setup script lives), in Unix form (slash-separated) for
|
root (where the setup script lives), in \UNIX{} form (slash-separated) for
|
||||||
portability. Source files may be C, \Cpp, SWIG (.i), platform-specific
|
portability. Source files may be C, \Cpp, SWIG (.i), platform-specific
|
||||||
resource files, or whatever else is recognized by the \command{build_ext}
|
resource files, or whatever else is recognized by the \command{build_ext}
|
||||||
command as source for a Python extension.}{string}
|
command as source for a Python extension.}{string}
|
||||||
|
|
@ -3099,7 +3099,7 @@ name of the output file, and \var{copied} is true if the file was copied
|
||||||
Move file \var{src} to \var{dst}. If \var{dst} is a directory, the file will
|
Move file \var{src} to \var{dst}. If \var{dst} is a directory, the file will
|
||||||
be moved into it with the same name; otherwise, \var{src} is just renamed
|
be moved into it with the same name; otherwise, \var{src} is just renamed
|
||||||
to \var{dst}. Returns the new full name of the file.
|
to \var{dst}. Returns the new full name of the file.
|
||||||
\warning{Handles cross-device moves on Unix using \function{copy_file()}.
|
\warning{Handles cross-device moves on \UNIX{} using \function{copy_file()}.
|
||||||
What about other systems???}
|
What about other systems???}
|
||||||
\end{funcdesc}
|
\end{funcdesc}
|
||||||
|
|
||||||
|
|
@ -3142,7 +3142,7 @@ For non-\POSIX{} platforms, currently just returns \code{sys.platform}.
|
||||||
Return 'pathname' as a name that will work on the native filesystem,
|
Return 'pathname' as a name that will work on the native filesystem,
|
||||||
i.e. split it on '/' and put it back together again using the current
|
i.e. split it on '/' and put it back together again using the current
|
||||||
directory separator. Needed because filenames in the setup script are
|
directory separator. Needed because filenames in the setup script are
|
||||||
always supplied in Unix style, and have to be converted to the local
|
always supplied in \UNIX{} style, and have to be converted to the local
|
||||||
convention before we can actually use them in the filesystem. Raises
|
convention before we can actually use them in the filesystem. Raises
|
||||||
\exception{ValueError} on non-\UNIX-ish systems if \var{pathname} either
|
\exception{ValueError} on non-\UNIX-ish systems if \var{pathname} either
|
||||||
starts or ends with a slash.
|
starts or ends with a slash.
|
||||||
|
|
@ -3191,7 +3191,7 @@ with \var{prefix}.
|
||||||
\end{funcdesc}
|
\end{funcdesc}
|
||||||
|
|
||||||
\begin{funcdesc}{split_quoted}{s}
|
\begin{funcdesc}{split_quoted}{s}
|
||||||
Split a string up according to Unix shell-like rules for quotes and
|
Split a string up according to \UNIX{} shell-like rules for quotes and
|
||||||
backslashes. In short: words are delimited by spaces, as long as those
|
backslashes. In short: words are delimited by spaces, as long as those
|
||||||
spaces are not escaped by a backslash, or inside a quoted string.
|
spaces are not escaped by a backslash, or inside a quoted string.
|
||||||
Single and double quotes are equivalent, and the quote characters can
|
Single and double quotes are equivalent, and the quote characters can
|
||||||
|
|
|
||||||
|
|
@ -262,7 +262,7 @@ If you don't choose an installation directory---i.e., if you just run
|
||||||
\code{setup.py install}---then the \command{install} command installs to
|
\code{setup.py install}---then the \command{install} command installs to
|
||||||
the standard location for third-party Python modules. This location
|
the standard location for third-party Python modules. This location
|
||||||
varies by platform and by how you built/installed Python itself. On
|
varies by platform and by how you built/installed Python itself. On
|
||||||
\UNIX{} (and Mac OS X, which is also Unix-based),
|
\UNIX{} (and Mac OS X, which is also \UNIX-based),
|
||||||
it also depends on whether the module distribution
|
it also depends on whether the module distribution
|
||||||
being installed is pure Python or contains extensions (``non-pure''):
|
being installed is pure Python or contains extensions (``non-pure''):
|
||||||
\begin{tableiv}{l|l|l|c}{textrm}%
|
\begin{tableiv}{l|l|l|c}{textrm}%
|
||||||
|
|
|
||||||
|
|
@ -31,11 +31,11 @@ Optional \var{mangle_from_} is a flag that, when \code{True}, puts a
|
||||||
\samp{>} character in front of any line in the body that starts exactly as
|
\samp{>} character in front of any line in the body that starts exactly as
|
||||||
\samp{From }, i.e. \code{From} followed by a space at the beginning of the
|
\samp{From }, i.e. \code{From} followed by a space at the beginning of the
|
||||||
line. This is the only guaranteed portable way to avoid having such
|
line. This is the only guaranteed portable way to avoid having such
|
||||||
lines be mistaken for a Unix mailbox format envelope header separator (see
|
lines be mistaken for a \UNIX{} mailbox format envelope header separator (see
|
||||||
\ulink{WHY THE CONTENT-LENGTH FORMAT IS BAD}
|
\ulink{WHY THE CONTENT-LENGTH FORMAT IS BAD}
|
||||||
{http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/content-length.html}
|
{http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/content-length.html}
|
||||||
for details). \var{mangle_from_} defaults to \code{True}, but you
|
for details). \var{mangle_from_} defaults to \code{True}, but you
|
||||||
might want to set this to \code{False} if you are not writing Unix
|
might want to set this to \code{False} if you are not writing \UNIX{}
|
||||||
mailbox format files.
|
mailbox format files.
|
||||||
|
|
||||||
Optional \var{maxheaderlen} specifies the longest length for a
|
Optional \var{maxheaderlen} specifies the longest length for a
|
||||||
|
|
|
||||||
|
|
@ -94,7 +94,7 @@ interpretation.
|
||||||
|
|
||||||
|
|
||||||
\begin{notice}
|
\begin{notice}
|
||||||
Beginning in 2.3 some Unix versions of Python may have a \module{bsddb185}
|
Beginning in 2.3 some \UNIX{} versions of Python may have a \module{bsddb185}
|
||||||
module. This is present \emph{only} to allow backwards compatibility with
|
module. This is present \emph{only} to allow backwards compatibility with
|
||||||
systems which ship with the old Berkeley DB 1.85 database library. The
|
systems which ship with the old Berkeley DB 1.85 database library. The
|
||||||
\module{bsddb185} module should never be used directly in new code.
|
\module{bsddb185} module should never be used directly in new code.
|
||||||
|
|
|
||||||
|
|
@ -724,7 +724,7 @@ class C:
|
||||||
In addition to the standard \cfunction{fopen()} values \var{mode}
|
In addition to the standard \cfunction{fopen()} values \var{mode}
|
||||||
may be \code{'U'} or \code{'rU'}. Python is usually built with universal
|
may be \code{'U'} or \code{'rU'}. Python is usually built with universal
|
||||||
newline support; supplying \code{'U'} opens the file as a text file, but
|
newline support; supplying \code{'U'} opens the file as a text file, but
|
||||||
lines may be terminated by any of the following: the Unix end-of-line
|
lines may be terminated by any of the following: the \UNIX{} end-of-line
|
||||||
convention \code{'\e n'},
|
convention \code{'\e n'},
|
||||||
the Macintosh convention \code{'\e r'}, or the Windows
|
the Macintosh convention \code{'\e r'}, or the Windows
|
||||||
convention \code{'\e r\e n'}. All of these external representations are seen as
|
convention \code{'\e r\e n'}. All of these external representations are seen as
|
||||||
|
|
|
||||||
|
|
@ -68,7 +68,7 @@ raises \exception{IOError}. Errors detected directly by
|
||||||
Open an audio device and return an OSS audio device object. This
|
Open an audio device and return an OSS audio device object. This
|
||||||
object supports many file-like methods, such as \method{read()},
|
object supports many file-like methods, such as \method{read()},
|
||||||
\method{write()}, and \method{fileno()} (although there are subtle
|
\method{write()}, and \method{fileno()} (although there are subtle
|
||||||
differences between conventional Unix read/write semantics and those of
|
differences between conventional \UNIX{} read/write semantics and those of
|
||||||
OSS audio devices). It also supports a number of audio-specific
|
OSS audio devices). It also supports a number of audio-specific
|
||||||
methods; see below for the complete list of methods.
|
methods; see below for the complete list of methods.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -74,9 +74,9 @@ synchronous servers of four types:
|
||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
|
|
||||||
Note that \class{UnixDatagramServer} derives from \class{UDPServer}, not
|
Note that \class{UnixDatagramServer} derives from \class{UDPServer}, not
|
||||||
from \class{UnixStreamServer} -- the only difference between an IP and a
|
from \class{UnixStreamServer} --- the only difference between an IP and a
|
||||||
Unix stream server is the address family, which is simply repeated in both
|
\UNIX{} stream server is the address family, which is simply repeated in both
|
||||||
unix server classes.
|
\UNIX{} server classes.
|
||||||
|
|
||||||
Forking and threading versions of each type of server can be created using
|
Forking and threading versions of each type of server can be created using
|
||||||
the \class{ForkingMixIn} and \class{ThreadingMixIn} mix-in classes. For
|
the \class{ForkingMixIn} and \class{ThreadingMixIn} mix-in classes. For
|
||||||
|
|
|
||||||
|
|
@ -512,10 +512,10 @@ The type/class to adapt must be a new-style class, i. e. it must have
|
||||||
\class{object} as one of its bases.
|
\class{object} as one of its bases.
|
||||||
\end{notice}
|
\end{notice}
|
||||||
|
|
||||||
The \module{sqlite3} module has two default adapters for Python's builtin
|
The \module{sqlite3} module has two default adapters for Python's built-in
|
||||||
\class{datetime.date} and \class{datetime.datetime} types. Now let's suppose we
|
\class{datetime.date} and \class{datetime.datetime} types. Now let's suppose
|
||||||
want to store \class{datetime.datetime} objects not in ISO representation, but
|
we want to store \class{datetime.datetime} objects not in ISO representation,
|
||||||
as Unix timestamp.
|
but as a \UNIX{} timestamp.
|
||||||
|
|
||||||
\verbatiminput{sqlite3/adapter_datetime.py}
|
\verbatiminput{sqlite3/adapter_datetime.py}
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -107,7 +107,7 @@ for the new process.
|
||||||
|
|
||||||
If \var{universal_newlines} is \constant{True}, the file objects stdout
|
If \var{universal_newlines} is \constant{True}, the file objects stdout
|
||||||
and stderr are opened as text files, but lines may be terminated by
|
and stderr are opened as text files, but lines may be terminated by
|
||||||
any of \code{'\e n'}, the Unix end-of-line convention, \code{'\e r'},
|
any of \code{'\e n'}, the \UNIX{} end-of-line convention, \code{'\e r'},
|
||||||
the Macintosh convention or \code{'\e r\e n'}, the Windows convention.
|
the Macintosh convention or \code{'\e r\e n'}, the Windows convention.
|
||||||
All of these external representations are seen as \code{'\e n'} by the
|
All of these external representations are seen as \code{'\e n'} by the
|
||||||
Python program. \note{This feature is only available if Python is built
|
Python program. \note{This feature is only available if Python is built
|
||||||
|
|
|
||||||
|
|
@ -258,14 +258,14 @@ It is always available.
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item On Windows 9x, the encoding is ``mbcs''.
|
\item On Windows 9x, the encoding is ``mbcs''.
|
||||||
\item On Mac OS X, the encoding is ``utf-8''.
|
\item On Mac OS X, the encoding is ``utf-8''.
|
||||||
\item On Unix, the encoding is the user's preference
|
\item On \UNIX, the encoding is the user's preference
|
||||||
according to the result of nl_langinfo(CODESET), or None if
|
according to the result of nl_langinfo(CODESET), or \constant{None}
|
||||||
the nl_langinfo(CODESET) failed.
|
if the \code{nl_langinfo(CODESET)} failed.
|
||||||
\item On Windows NT+, file names are Unicode natively, so no conversion
|
\item On Windows NT+, file names are Unicode natively, so no conversion
|
||||||
is performed. \code{getfilesystemencoding} still returns ``mbcs'',
|
is performed. \function{getfilesystemencoding()} still returns
|
||||||
as this is the encoding that applications should use when they
|
\code{'mbcs'}, as this is the encoding that applications should use
|
||||||
explicitly want to convert Unicode strings to byte strings that
|
when they explicitly want to convert Unicode strings to byte strings
|
||||||
are equivalent when used as file names.
|
that are equivalent when used as file names.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
\versionadded{2.3}
|
\versionadded{2.3}
|
||||||
\end{funcdesc}
|
\end{funcdesc}
|
||||||
|
|
|
||||||
|
|
@ -427,7 +427,7 @@ Where:
|
||||||
'16:08:12 05/08/03 AEST'
|
'16:08:12 05/08/03 AEST'
|
||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
|
|
||||||
On many Unix systems (including *BSD, Linux, Solaris, and Darwin), it
|
On many \UNIX{} systems (including *BSD, Linux, Solaris, and Darwin), it
|
||||||
is more convenient to use the system's zoneinfo (\manpage{tzfile}{5})
|
is more convenient to use the system's zoneinfo (\manpage{tzfile}{5})
|
||||||
database to specify the timezone rules. To do this, set the
|
database to specify the timezone rules. To do this, set the
|
||||||
\envvar{TZ} environment variable to the path of the required timezone
|
\envvar{TZ} environment variable to the path of the required timezone
|
||||||
|
|
|
||||||
|
|
@ -49,7 +49,7 @@ document these.
|
||||||
|
|
||||||
\item[\module{bsddb185}]
|
\item[\module{bsddb185}]
|
||||||
--- Backwards compatibility module for systems which still use the Berkeley
|
--- Backwards compatibility module for systems which still use the Berkeley
|
||||||
DB 1.85 module. It is normally only available on certain BSD Unix-based
|
DB 1.85 module. It is normally only available on certain BSD \UNIX-based
|
||||||
systems. It should never be used directly.
|
systems. It should never be used directly.
|
||||||
\end{description}
|
\end{description}
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -106,12 +106,12 @@ cat myzip.zip >> python.exe
|
||||||
is specified but the \refmodule{zlib} module is not available,
|
is specified but the \refmodule{zlib} module is not available,
|
||||||
\exception{RuntimeError} is also raised. The default is
|
\exception{RuntimeError} is also raised. The default is
|
||||||
\constant{ZIP_STORED}.
|
\constant{ZIP_STORED}.
|
||||||
If \var{allowZip64} is \code{True} zipfile will create zipfiles that use
|
If \var{allowZip64} is \code{True} zipfile will create ZIP files that use
|
||||||
the ZIP64 extensions when the zipfile is larger than 2GBytes. If it is
|
the ZIP64 extensions when the zipfile is larger than 2 GB. If it is
|
||||||
false (the default) zipfile will raise an exception when the zipfile would
|
false (the default) \module{zipfile} will raise an exception when the
|
||||||
require ZIP64 extensions. ZIP64 extensions are disabled by default because
|
ZIP file would require ZIP64 extensions. ZIP64 extensions are disabled by
|
||||||
the default zip and unzip commands on Unix (the InfoZIP utilities) don't
|
default because the default \program{zip} and \program{unzip} commands on
|
||||||
support these extensions.
|
\UNIX{} (the InfoZIP utilities) don't support these extensions.
|
||||||
\end{classdesc}
|
\end{classdesc}
|
||||||
|
|
||||||
\begin{methoddesc}{close}{}
|
\begin{methoddesc}{close}{}
|
||||||
|
|
|
||||||
|
|
@ -24,7 +24,7 @@ pathname, (2) an \class{FSSpec} object or (3) a 3-tuple
|
||||||
\code{(\var{wdRefNum}, \var{parID}, \var{name})} as described in
|
\code{(\var{wdRefNum}, \var{parID}, \var{name})} as described in
|
||||||
\citetitle{Inside Macintosh:\ Files}. An \class{FSSpec} can point to
|
\citetitle{Inside Macintosh:\ Files}. An \class{FSSpec} can point to
|
||||||
a non-existing file, as long as the folder containing the file exists.
|
a non-existing file, as long as the folder containing the file exists.
|
||||||
Under MacPython the same is true for a pathname, but not under unix-Pyton
|
Under MacPython the same is true for a pathname, but not under \UNIX-Python
|
||||||
because of the way pathnames and FSRefs works. See Apple's documentation
|
because of the way pathnames and FSRefs works. See Apple's documentation
|
||||||
for details.
|
for details.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -25,7 +25,7 @@ The way the interpreter has been linked. As extension modules may be
|
||||||
incompatible between linking models, packages could use this information to give
|
incompatible between linking models, packages could use this information to give
|
||||||
more decent error messages. The value is one of \code{'static'} for a
|
more decent error messages. The value is one of \code{'static'} for a
|
||||||
statically linked Python, \code{'framework'} for Python in a Mac OS X framework,
|
statically linked Python, \code{'framework'} for Python in a Mac OS X framework,
|
||||||
\code{'shared'} for Python in a standard unix shared library.
|
\code{'shared'} for Python in a standard \UNIX{} shared library.
|
||||||
Older Pythons could also have the value
|
Older Pythons could also have the value
|
||||||
\code{'cfm'} for Mac OS 9-compatible Python.
|
\code{'cfm'} for Mac OS 9-compatible Python.
|
||||||
\end{datadesc}
|
\end{datadesc}
|
||||||
|
|
|
||||||
|
|
@ -6,7 +6,7 @@ Python on any other \UNIX platform, but there are a number of additional
|
||||||
features such as the IDE and the Package Manager that are worth pointing out.
|
features such as the IDE and the Package Manager that are worth pointing out.
|
||||||
|
|
||||||
Python on Mac OS 9 or earlier can be quite different from Python on
|
Python on Mac OS 9 or earlier can be quite different from Python on
|
||||||
Unix or Windows, but is beyond the scope of this manual, as that platform
|
\UNIX{} or Windows, but is beyond the scope of this manual, as that platform
|
||||||
is no longer supported, starting with Python 2.4. See
|
is no longer supported, starting with Python 2.4. See
|
||||||
\url{http://www.cwi.nl/\textasciitilde jack/macpython} for installers
|
\url{http://www.cwi.nl/\textasciitilde jack/macpython} for installers
|
||||||
for the latest 2.3 release for Mac OS 9 and related documentation.
|
for the latest 2.3 release for Mac OS 9 and related documentation.
|
||||||
|
|
|
||||||
|
|
@ -571,7 +571,7 @@ def f(*args, **kw):
|
||||||
|
|
||||||
The \keyword{print} statement can now have its output directed to a
|
The \keyword{print} statement can now have its output directed to a
|
||||||
file-like object by following the \keyword{print} with
|
file-like object by following the \keyword{print} with
|
||||||
\verb|>> file|, similar to the redirection operator in Unix shells.
|
\verb|>> file|, similar to the redirection operator in \UNIX{} shells.
|
||||||
Previously you'd either have to use the \method{write()} method of the
|
Previously you'd either have to use the \method{write()} method of the
|
||||||
file-like object, which lacks the convenience and simplicity of
|
file-like object, which lacks the convenience and simplicity of
|
||||||
\keyword{print}, or you could assign a new value to
|
\keyword{print}, or you could assign a new value to
|
||||||
|
|
@ -894,7 +894,7 @@ to be added, and a third argument for the value to be assigned to the
|
||||||
name. This third argument is, respectively, a Python object, a C
|
name. This third argument is, respectively, a Python object, a C
|
||||||
long, or a C string.
|
long, or a C string.
|
||||||
|
|
||||||
A wrapper API was added for Unix-style signal handlers.
|
A wrapper API was added for \UNIX-style signal handlers.
|
||||||
\function{PyOS_getsig()} gets a signal handler and
|
\function{PyOS_getsig()} gets a signal handler and
|
||||||
\function{PyOS_setsig()} will set a new handler.
|
\function{PyOS_setsig()} will set a new handler.
|
||||||
|
|
||||||
|
|
@ -905,7 +905,7 @@ Before Python 2.0, installing modules was a tedious affair -- there
|
||||||
was no way to figure out automatically where Python is installed, or
|
was no way to figure out automatically where Python is installed, or
|
||||||
what compiler options to use for extension modules. Software authors
|
what compiler options to use for extension modules. Software authors
|
||||||
had to go through an arduous ritual of editing Makefiles and
|
had to go through an arduous ritual of editing Makefiles and
|
||||||
configuration files, which only really work on Unix and leave Windows
|
configuration files, which only really work on \UNIX{} and leave Windows
|
||||||
and MacOS unsupported. Python users faced wildly differing
|
and MacOS unsupported. Python users faced wildly differing
|
||||||
installation instructions which varied between different extension
|
installation instructions which varied between different extension
|
||||||
packages, which made administering a Python installation something of
|
packages, which made administering a Python installation something of
|
||||||
|
|
@ -1222,7 +1222,7 @@ device on Linux, a twin to the existing \module{sunaudiodev} module.
|
||||||
(Contributed by Peter Bosch, with fixes by Jeremy Hylton.)
|
(Contributed by Peter Bosch, with fixes by Jeremy Hylton.)
|
||||||
|
|
||||||
\item{\module{mmap}:} An interface to memory-mapped files on both
|
\item{\module{mmap}:} An interface to memory-mapped files on both
|
||||||
Windows and Unix. A file's contents can be mapped directly into
|
Windows and \UNIX. A file's contents can be mapped directly into
|
||||||
memory, at which point it behaves like a mutable string, so its
|
memory, at which point it behaves like a mutable string, so its
|
||||||
contents can be read and modified. They can even be passed to
|
contents can be read and modified. They can even be passed to
|
||||||
functions that expect ordinary strings, such as the \module{re}
|
functions that expect ordinary strings, such as the \module{re}
|
||||||
|
|
@ -1262,7 +1262,7 @@ distribution, and enhanced to support Unicode.
|
||||||
|
|
||||||
\item{\module{zipfile}:} A module for reading and writing ZIP-format
|
\item{\module{zipfile}:} A module for reading and writing ZIP-format
|
||||||
archives. These are archives produced by \program{PKZIP} on
|
archives. These are archives produced by \program{PKZIP} on
|
||||||
DOS/Windows or \program{zip} on Unix, not to be confused with
|
DOS/Windows or \program{zip} on \UNIX, not to be confused with
|
||||||
\program{gzip}-format files (which are supported by the \module{gzip}
|
\program{gzip}-format files (which are supported by the \module{gzip}
|
||||||
module)
|
module)
|
||||||
(Contributed by James C. Ahlstrom.)
|
(Contributed by James C. Ahlstrom.)
|
||||||
|
|
|
||||||
|
|
@ -325,7 +325,7 @@ Rossum.}
|
||||||
When compiling Python, the user had to go in and edit the
|
When compiling Python, the user had to go in and edit the
|
||||||
\file{Modules/Setup} file in order to enable various additional
|
\file{Modules/Setup} file in order to enable various additional
|
||||||
modules; the default set is relatively small and limited to modules
|
modules; the default set is relatively small and limited to modules
|
||||||
that compile on most Unix platforms. This means that on Unix
|
that compile on most \UNIX{} platforms. This means that on \Unix{}
|
||||||
platforms with many more features, most notably Linux, Python
|
platforms with many more features, most notably Linux, Python
|
||||||
installations often don't contain all useful modules they could.
|
installations often don't contain all useful modules they could.
|
||||||
|
|
||||||
|
|
@ -661,7 +661,7 @@ PyUnit.
|
||||||
\item The \module{difflib} module contains a class,
|
\item The \module{difflib} module contains a class,
|
||||||
\class{SequenceMatcher}, which compares two sequences and computes the
|
\class{SequenceMatcher}, which compares two sequences and computes the
|
||||||
changes required to transform one sequence into the other. For
|
changes required to transform one sequence into the other. For
|
||||||
example, this module can be used to write a tool similar to the Unix
|
example, this module can be used to write a tool similar to the \UNIX{}
|
||||||
\program{diff} program, and in fact the sample program
|
\program{diff} program, and in fact the sample program
|
||||||
\file{Tools/scripts/ndiff.py} demonstrates how to write such a script.
|
\file{Tools/scripts/ndiff.py} demonstrates how to write such a script.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1979,7 +1979,7 @@ documentation}{../lib/module-datetime.html}.
|
||||||
|
|
||||||
The \module{getopt} module provides simple parsing of command-line
|
The \module{getopt} module provides simple parsing of command-line
|
||||||
arguments. The new \module{optparse} module (originally named Optik)
|
arguments. The new \module{optparse} module (originally named Optik)
|
||||||
provides more elaborate command-line parsing that follows the Unix
|
provides more elaborate command-line parsing that follows the \UNIX{}
|
||||||
conventions, automatically creates the output for \longprogramopt{help},
|
conventions, automatically creates the output for \longprogramopt{help},
|
||||||
and can perform different actions for different options.
|
and can perform different actions for different options.
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue