Compiling the interpreter with the \csimplemacro{Py_DEBUG} macro
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
implied by the presence of the not-Python-specific
\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
following extra checks are performed:
you can take advantage of the fact that header files are installed in a
consistent way by the Distutils \command{install\_header} command. For
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
installation.) Since the Python include
directory---\file{/usr/local/include/python1.5} in this case---is always
\lineiii{name}{the full name of the extension, including any packages
--- ie. \emph{not} a filename or pathname, but Python dotted name}{string}
\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
resource files, or whatever else is recognized by the \command{build_ext}
command as source for a Python extension.}{string}
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
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???}
\end{funcdesc}
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
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
\exception{ValueError} on non-\UNIX-ish systems if \var{pathname} either
starts or ends with a slash.
\end{funcdesc}
\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
spaces are not escaped by a backslash, or inside a quoted string.
Single and double quotes are equivalent, and the quote characters can
\code{setup.py install}---then the \command{install} command installs to
the standard location for third-party Python modules. This location
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
being installed is pure Python or contains extensions (``non-pure''):
\begin{tableiv}{l|l|l|c}{textrm}%
\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
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}
{http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/content-length.html}
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.
Optional \var{maxheaderlen} specifies the longest length for a
\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
systems which ship with the old Berkeley DB 1.85 database library. The
\module{bsddb185} module should never be used directly in new code.
In addition to the standard \cfunction{fopen()} values \var{mode}
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
- 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'},
the Macintosh convention \code{'\e r'}, or the Windows
convention \code{'\e r\e n'}. All of these external representations are seen as
Open an audio device and return an OSS audio device object. This
object supports many file-like methods, such as \method{read()},
\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
methods; see below for the complete list of methods.
\end{verbatim}
Note that \class{UnixDatagramServer} derives from \class{UDPServer}, not
-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 server classes.
+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{} server classes.
Forking and threading versions of each type of server can be created using
the \class{ForkingMixIn} and \class{ThreadingMixIn} mix-in classes. For
\class{object} as one of its bases.
\end{notice}
-The \module{sqlite3} module has two default adapters for Python's builtin
-\class{datetime.date} and \class{datetime.datetime} types. Now let's suppose we
-want to store \class{datetime.datetime} objects not in ISO representation, but
-as Unix timestamp.
+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 want to store \class{datetime.datetime} objects not in ISO representation,
+but as a \UNIX{} timestamp.
\verbatiminput{sqlite3/adapter_datetime.py}
If \var{universal_newlines} is \constant{True}, the file objects stdout
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.
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
\begin{itemize}
\item On Windows 9x, the encoding is ``mbcs''.
\item On Mac OS X, the encoding is ``utf-8''.
-\item On Unix, the encoding is the user's preference
- according to the result of nl_langinfo(CODESET), or None if
- the nl_langinfo(CODESET) failed.
+\item On \UNIX, the encoding is the user's preference
+ according to the result of nl_langinfo(CODESET), or \constant{None}
+ if the \code{nl_langinfo(CODESET)} failed.
\item On Windows NT+, file names are Unicode natively, so no conversion
- is performed. \code{getfilesystemencoding} still returns ``mbcs'',
- as this is the encoding that applications should use when they
- explicitly want to convert Unicode strings to byte strings that
- are equivalent when used as file names.
+ is performed. \function{getfilesystemencoding()} still returns
+ \code{'mbcs'}, as this is the encoding that applications should use
+ when they explicitly want to convert Unicode strings to byte strings
+ that are equivalent when used as file names.
\end{itemize}
\versionadded{2.3}
\end{funcdesc}
'16:08:12 05/08/03 AEST'
\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})
database to specify the timezone rules. To do this, set the
\envvar{TZ} environment variable to the path of the required timezone
\item[\module{bsddb185}]
--- 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.
\end{description}
is specified but the \refmodule{zlib} module is not available,
\exception{RuntimeError} is also raised. The default is
\constant{ZIP_STORED}.
- If \var{allowZip64} is \code{True} zipfile will create zipfiles that use
- the ZIP64 extensions when the zipfile is larger than 2GBytes. If it is
- false (the default) zipfile will raise an exception when the zipfile would
- require ZIP64 extensions. ZIP64 extensions are disabled by default because
- the default zip and unzip commands on Unix (the InfoZIP utilities) don't
- support these extensions.
+ If \var{allowZip64} is \code{True} zipfile will create ZIP files that use
+ the ZIP64 extensions when the zipfile is larger than 2 GB. If it is
+ false (the default) \module{zipfile} will raise an exception when the
+ ZIP file would require ZIP64 extensions. ZIP64 extensions are disabled by
+ default because the default \program{zip} and \program{unzip} commands on
+ \UNIX{} (the InfoZIP utilities) don't support these extensions.
\end{classdesc}
\begin{methoddesc}{close}{}
argument can be one of three things:\ (1) a full or partial Macintosh
pathname, (2) an \class{FSSpec} object or (3) a 3-tuple
\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.
-Under MacPython the same is true for a pathname, but not under unix-Pyton
-because of the way pathnames and FSRefs works. See Apple's documentation
+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
for details.
A description of aliases and the
incompatible between linking models, packages could use this information to give
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,
-\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
\code{'cfm'} for Mac OS 9-compatible Python.
\end{datadesc}
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
-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
\url{http://www.cwi.nl/\textasciitilde jack/macpython} for installers
for the latest 2.3 release for Mac OS 9 and related documentation.
The \keyword{print} statement can now have its output directed to a
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
file-like object, which lacks the convenience and simplicity of
\keyword{print}, or you could assign a new value to
name. This third argument is, respectively, a Python object, a C
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_setsig()} will set a new handler.
was no way to figure out automatically where Python is installed, or
what compiler options to use for extension modules. Software authors
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
installation instructions which varied between different extension
packages, which made administering a Python installation something of
(Contributed by Peter Bosch, with fixes by Jeremy Hylton.)
\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
contents can be read and modified. They can even be passed to
functions that expect ordinary strings, such as the \module{re}
\item{\module{zipfile}:} A module for reading and writing ZIP-format
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}
module)
(Contributed by James C. Ahlstrom.)
When compiling Python, the user had to go in and edit the
\file{Modules/Setup} file in order to enable various additional
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
installations often don't contain all useful modules they could.
\item The \module{difflib} module contains a class,
\class{SequenceMatcher}, which compares two sequences and computes the
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
\file{Tools/scripts/ndiff.py} demonstrates how to write such a script.
The \module{getopt} module provides simple parsing of command-line
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},
and can perform different actions for different options.
projects / python / commitdiff