summaryrefslogtreecommitdiffstats
path: root/Doc
diff options
context:
space:
mode:
Diffstat (limited to 'Doc')
-rw-r--r--Doc/distutils/apiref.rst24
-rw-r--r--Doc/distutils/builtdist.rst32
-rw-r--r--Doc/distutils/configfile.rst6
-rw-r--r--Doc/distutils/extending.rst2
-rw-r--r--Doc/distutils/setupscript.rst2
-rw-r--r--Doc/distutils/sourcedist.rst12
-rw-r--r--Doc/extending/extending.rst2
-rw-r--r--Doc/install/index.rst50
-rw-r--r--Doc/library/2to3.rst28
-rw-r--r--Doc/library/ctypes.rst4
-rw-r--r--Doc/library/gettext.rst2
-rw-r--r--Doc/library/warnings.rst6
-rw-r--r--Doc/using/cmdline.rst4
-rw-r--r--Doc/whatsnew/2.0.rst2
-rw-r--r--Doc/whatsnew/2.1.rst2
-rw-r--r--Doc/whatsnew/2.2.rst8
-rw-r--r--Doc/whatsnew/2.3.rst14
-rw-r--r--Doc/whatsnew/2.4.rst6
-rw-r--r--Doc/whatsnew/2.5.rst6
-rw-r--r--Doc/whatsnew/2.6.rst4
-rw-r--r--Doc/whatsnew/2.7.rst26
-rw-r--r--Doc/whatsnew/3.0.rst2
22 files changed, 122 insertions, 122 deletions
diff --git a/Doc/distutils/apiref.rst b/Doc/distutils/apiref.rst
index 0672253..be0e89a 100644
--- a/Doc/distutils/apiref.rst
+++ b/Doc/distutils/apiref.rst
@@ -205,7 +205,7 @@ the full reference.
| | to or ``None`` to define it | |
| | without a particular value | |
| | (equivalent of ``#define FOO`` | |
- | | in source or :option:`-DFOO` | |
+ | | in source or :option:`!-DFOO` | |
| | on Unix C compiler command | |
| | line) | |
+------------------------+--------------------------------+---------------------------+
@@ -319,11 +319,11 @@ This module provides the following functions.
.. function:: gen_preprocess_options(macros, include_dirs)
- Generate C pre-processor options (:option:`-D`, :option:`!-U`, :option:`!-I`) as
+ Generate C pre-processor options (:option:`!-D`, :option:`!-U`, :option:`!-I`) as
used by at least two types of compilers: the typical Unix compiler and Visual
C++. *macros* is the usual thing, a list of 1- or 2-tuples, where ``(name,)``
means undefine (:option:`!-U`) macro *name*, and ``(name, value)`` means define
- (:option:`-D`) macro *name* to *value*. *include_dirs* is just a list of
+ (:option:`!-D`) macro *name* to *value*. *include_dirs* is just a list of
directory names to be added to the header file search path (:option:`!-I`).
Returns a list of command-line options suitable for either Unix compilers or
Visual C++.
@@ -359,7 +359,7 @@ This module provides the following functions.
.. function:: show_compilers()
- Print list of available compilers (used by the :option:`--help-compiler` options
+ Print list of available compilers (used by the :option:`!--help-compiler` options
to :command:`build`, :command:`build_ext`, :command:`build_clib`).
@@ -789,15 +789,15 @@ This module provides the following functions.
This module provides the :class:`UnixCCompiler` class, a subclass of
:class:`CCompiler` that handles the typical Unix-style command-line C compiler:
-* macros defined with :option:`-Dname[=value]`
+* macros defined with :option:`!-Dname[=value]`
-* macros undefined with :option:`-Uname`
+* macros undefined with :option:`!-Uname`
-* include search directories specified with :option:`-Idir`
+* include search directories specified with :option:`!-Idir`
-* libraries specified with :option:`-llib`
+* libraries specified with :option:`!-llib`
-* library search directories specified with :option:`-Ldir`
+* library search directories specified with :option:`!-Ldir`
* compile handled by :program:`cc` (or similar) executable with :option:`!-c`
option: compiles :file:`.c` to :file:`.o`
@@ -805,7 +805,7 @@ This module provides the :class:`UnixCCompiler` class, a subclass of
* link static library handled by :program:`ar` command (possibly with
:program:`ranlib`)
-* link shared library handled by :program:`cc` :option:`-shared`
+* link shared library handled by :program:`cc` :option:`!-shared`
:mod:`distutils.msvccompiler` --- Microsoft Compiler
@@ -1318,8 +1318,8 @@ provides the following additional features:
* options set attributes of a passed-in object
-* boolean options can have "negative aliases" --- eg. if :option:`--quiet` is
- the "negative alias" of :option:`--verbose`, then :option:`--quiet` on the
+* boolean options can have "negative aliases" --- eg. if :option:`!--quiet` is
+ the "negative alias" of :option:`!--verbose`, then :option:`!--quiet` on the
command line sets *verbose* to false.
.. function:: fancy_getopt(options, negative_opt, object, args)
diff --git a/Doc/distutils/builtdist.rst b/Doc/distutils/builtdist.rst
index 523d1e0..bbd2a8c 100644
--- a/Doc/distutils/builtdist.rst
+++ b/Doc/distutils/builtdist.rst
@@ -57,7 +57,7 @@ built distributions, such as an RPM package or an executable installer for
Windows, is far more convenient for users even if your distribution doesn't
include any extensions.
-The :command:`bdist` command has a :option:`--formats` option, similar to the
+The :command:`bdist` command has a :option:`!--formats` option, similar to the
:command:`sdist` command, which you can use to select the types of built
distribution to generate: for example, ::
@@ -123,7 +123,7 @@ Notes:
requires external :program:`rpm` utility, version 3.0.4 or better (use ``rpm
--version`` to find out which version you have)
-You don't have to use the :command:`bdist` command with the :option:`--formats`
+You don't have to use the :command:`bdist` command with the :option:`!--formats`
option; you can also use the command that directly implements the format you're
interested in. Some of these :command:`bdist` "sub-commands" actually generate
several similar formats; for instance, the :command:`bdist_dumb` command
@@ -174,7 +174,7 @@ The usual way to create an RPM of your module distribution is to run the
python setup.py bdist_rpm
-or the :command:`bdist` command with the :option:`--format` option::
+or the :command:`bdist` command with the :option:`!--format` option::
python setup.py bdist --formats=rpm
@@ -249,7 +249,7 @@ configuration file, :file:`setup.cfg`\ ---see section :ref:`setup-config`. If
you distribute or package many Python module distributions, you might want to
put options that apply to all of them in your personal Distutils configuration
file (:file:`~/.pydistutils.cfg`). If you want to temporarily disable
-this file, you can pass the :option:`--no-user-cfg` option to :file:`setup.py`.
+this file, you can pass the :option:`!--no-user-cfg` option to :file:`setup.py`.
There are three steps to building a binary RPM package, all of which are
handled automatically by the Distutils:
@@ -267,10 +267,10 @@ Normally, RPM bundles the last two steps together; when you use the Distutils,
all three steps are typically bundled together.
If you wish, you can separate these three steps. You can use the
-:option:`--spec-only` option to make :command:`bdist_rpm` just create the
+:option:`!--spec-only` option to make :command:`bdist_rpm` just create the
:file:`.spec` file and exit; in this case, the :file:`.spec` file will be
written to the "distribution directory"---normally :file:`dist/`, but
-customizable with the :option:`--dist-dir` option. (Normally, the :file:`.spec`
+customizable with the :option:`!--dist-dir` option. (Normally, the :file:`.spec`
file winds up deep in the "build tree," in a temporary directory created by
:command:`bdist_rpm`.)
@@ -307,7 +307,7 @@ is usually as easy as running::
python setup.py bdist_wininst
-or the :command:`bdist` command with the :option:`--formats` option::
+or the :command:`bdist` command with the :option:`!--formats` option::
python setup.py bdist --formats=wininst
@@ -325,20 +325,20 @@ support.
The installer will try to compile pure modules into :term:`bytecode` after installation
on the target system in normal and optimizing mode. If you don't want this to
happen for some reason, you can run the :command:`bdist_wininst` command with
-the :option:`--no-target-compile` and/or the :option:`--no-target-optimize`
+the :option:`!--no-target-compile` and/or the :option:`!--no-target-optimize`
option.
By default the installer will display the cool "Python Powered" logo when it is
run, but you can also supply your own 152x261 bitmap which must be a Windows
-:file:`.bmp` file with the :option:`--bitmap` option.
+:file:`.bmp` file with the :option:`!--bitmap` option.
The installer will also display a large title on the desktop background window
when it is run, which is constructed from the name of your distribution and the
version number. This can be changed to another text by using the
-:option:`--title` option.
+:option:`!--title` option.
The installer file will be written to the "distribution directory" --- normally
-:file:`dist/`, but customizable with the :option:`--dist-dir` option.
+:file:`dist/`, but customizable with the :option:`!--dist-dir` option.
.. _cross-compile-windows:
@@ -350,7 +350,7 @@ Windows platforms. In practice, this means that with the correct tools
installed, you can use a 32bit version of Windows to create 64bit extensions
and vice-versa.
-To build for an alternate platform, specify the :option:`--plat-name` option
+To build for an alternate platform, specify the :option:`!--plat-name` option
to the build command. Valid values are currently 'win32', 'win-amd64' and
'win-ia64'. For example, on a 32bit version of Windows, you could execute::
@@ -383,14 +383,14 @@ The Postinstallation script
---------------------------
Starting with Python 2.3, a postinstallation script can be specified with the
-:option:`--install-script` option. The basename of the script must be
+:option:`!--install-script` option. The basename of the script must be
specified, and the script filename must also be listed in the scripts argument
to the setup function.
This script will be run at installation time on the target system after all the
-files have been copied, with ``argv[1]`` set to :option:`-install`, and again at
+files have been copied, with ``argv[1]`` set to :option:`!-install`, and again at
uninstallation time before the files are removed with ``argv[1]`` set to
-:option:`-remove`.
+:option:`!-remove`.
The installation script runs embedded in the windows installer, every output
(``sys.stdout``, ``sys.stderr``) is redirected into a buffer and will be
@@ -453,7 +453,7 @@ built-in functions in the installation script.
Vista User Access Control (UAC)
===============================
-Starting with Python 2.6, bdist_wininst supports a :option:`--user-access-control`
+Starting with Python 2.6, bdist_wininst supports a :option:`!--user-access-control`
option. The default is 'none' (meaning no UAC handling is done), and other
valid values are 'auto' (meaning prompt for UAC elevation if Python was
installed for all users) and 'force' (meaning always prompt for elevation).
diff --git a/Doc/distutils/configfile.rst b/Doc/distutils/configfile.rst
index 51d8897..21f1acd 100644
--- a/Doc/distutils/configfile.rst
+++ b/Doc/distutils/configfile.rst
@@ -66,7 +66,7 @@ universal :option:`!--help` option, e.g. ::
--swig-opts list of SWIG command line options
[...]
-Note that an option spelled :option:`--foo-bar` on the command-line is spelled
+Note that an option spelled :option:`!--foo-bar` on the command-line is spelled
``foo_bar`` in configuration files.
.. _distutils-build-ext-inplace:
@@ -75,12 +75,12 @@ For example, say you want your extensions to be built "in-place"---that is, you
have an extension :mod:`pkg.ext`, and you want the compiled extension file
(:file:`ext.so` on Unix, say) to be put in the same source directory as your
pure Python modules :mod:`pkg.mod1` and :mod:`pkg.mod2`. You can always use the
-:option:`--inplace` option on the command-line to ensure this::
+:option:`!--inplace` option on the command-line to ensure this::
python setup.py build_ext --inplace
But this requires that you always specify the :command:`build_ext` command
-explicitly, and remember to provide :option:`--inplace`. An easier way is to
+explicitly, and remember to provide :option:`!--inplace`. An easier way is to
"set and forget" this option, by encoding it in :file:`setup.cfg`, the
configuration file for this distribution::
diff --git a/Doc/distutils/extending.rst b/Doc/distutils/extending.rst
index 5139c6d..501fd7c 100644
--- a/Doc/distutils/extending.rst
+++ b/Doc/distutils/extending.rst
@@ -62,7 +62,7 @@ requiring modifications to the Python installation. This is expected to allow
third-party extensions to provide support for additional packaging systems, but
the commands can be used for anything distutils commands can be used for. A new
configuration option, ``command_packages`` (command-line option
-:option:`--command-packages`), can be used to specify additional packages to be
+:option:`!--command-packages`), can be used to specify additional packages to be
searched for modules implementing commands. Like all distutils options, this
can be specified on the command line or in a configuration file. This option
can only be set in the ``[global]`` section of a configuration file, or before
diff --git a/Doc/distutils/setupscript.rst b/Doc/distutils/setupscript.rst
index 914a34f..9c4a9d5 100644
--- a/Doc/distutils/setupscript.rst
+++ b/Doc/distutils/setupscript.rst
@@ -446,7 +446,7 @@ command line. Scripts don't require Distutils to do anything very complicated.
The only clever feature is that if the first line of the script starts with
``#!`` and contains the word "python", the Distutils will adjust the first line
to refer to the current interpreter location. By default, it is replaced with
-the current interpreter location. The :option:`--executable` (or :option:`-e`)
+the current interpreter location. The :option:`!--executable` (or :option:`!-e`)
option will allow the interpreter path to be explicitly overridden.
The ``scripts`` option simply is a list of files to be handled in this
diff --git a/Doc/distutils/sourcedist.rst b/Doc/distutils/sourcedist.rst
index 35aea1e..cc289c9 100644
--- a/Doc/distutils/sourcedist.rst
+++ b/Doc/distutils/sourcedist.rst
@@ -14,7 +14,7 @@ or config file), :command:`sdist` creates the archive of the default format for
the current platform. The default format is a gzip'ed tar file
(:file:`.tar.gz`) on Unix, and ZIP file on Windows.
-You can specify as many formats as you like using the :option:`--formats`
+You can specify as many formats as you like using the :option:`!--formats`
option, for example::
python setup.py sdist --formats=gztar,zip
@@ -147,7 +147,7 @@ matching :file:`\*.txt` or :file:`\*.py`, and exclude all directories matching
:file:`examples/sample?/build`. All of this is done *after* the standard
include set, so you can exclude files from the standard set with explicit
instructions in the manifest template. (Or, you can use the
-:option:`--no-defaults` option to disable the standard set entirely.) There are
+:option:`!--no-defaults` option to disable the standard set entirely.) There are
several other commands available in the manifest template mini-language; see
section :ref:`sdist-cmd`.
@@ -166,8 +166,8 @@ Now we have our complete list of files, which is written to the manifest for
future reference, and then used to build the source distribution archive(s).
You can disable the default set of included files with the
-:option:`--no-defaults` option, and you can disable the standard exclude set
-with :option:`--no-prune`.
+:option:`!--no-defaults` option, and you can disable the standard exclude set
+with :option:`!--no-prune`.
Following the Distutils' own manifest template, let's trace how the
:command:`sdist` command builds the list of files to include in the Distutils
@@ -225,7 +225,7 @@ The normal course of operations for the :command:`sdist` command is as follows:
in) to create the source distribution archive(s)
There are a couple of options that modify this behaviour. First, use the
-:option:`--no-defaults` and :option:`--no-prune` to disable the standard
+:option:`!--no-defaults` and :option:`!--no-prune` to disable the standard
"include" and "exclude" sets.
Second, you might just want to (re)generate the manifest, but not create a source
@@ -233,4 +233,4 @@ distribution::
python setup.py sdist --manifest-only
-:option:`-o` is a shortcut for :option:`--manifest-only`.
+:option:`!-o` is a shortcut for :option:`!--manifest-only`.
diff --git a/Doc/extending/extending.rst b/Doc/extending/extending.rst
index 8219707..4ac820a 100644
--- a/Doc/extending/extending.rst
+++ b/Doc/extending/extending.rst
@@ -886,7 +886,7 @@ The :mod:`gc` module exposes a way to run the detector (the
:func:`~gc.collect` function), as well as configuration
interfaces and the ability to disable the detector at runtime. The cycle
detector is considered an optional component; though it is included by default,
-it can be disabled at build time using the :option:`--without-cycle-gc` option
+it can be disabled at build time using the :option:`!--without-cycle-gc` option
to the :program:`configure` script on Unix platforms (including Mac OS X). If
the cycle detector is disabled in this way, the :mod:`gc` module will not be
available.
diff --git a/Doc/install/index.rst b/Doc/install/index.rst
index b22fc59..bc080b0 100644
--- a/Doc/install/index.rst
+++ b/Doc/install/index.rst
@@ -201,7 +201,7 @@ As implied above, the :command:`build` command is responsible for putting the
files to install into a *build directory*. By default, this is :file:`build`
under the distribution root; if you're excessively concerned with speed, or want
to keep the source tree pristine, you can change the build directory with the
-:option:`--build-base` option. For example::
+:option:`!--build-base` option. For example::
python setup.py build --build-base=/path/to/pybuild/foo-1.0
@@ -399,7 +399,7 @@ Installing a new module distribution is as simple as ::
python setup.py install --home=<dir>
-where you can supply any directory you like for the :option:`--home` option. On
+where you can supply any directory you like for the :option:`!--home` option. On
Unix, lazy typists can just type a tilde (``~``); the :command:`install` command
will expand this to your home directory::
@@ -410,7 +410,7 @@ to :ref:`modify Python's search path <inst-search-path>` or edit
:mod:`sitecustomize` (see :mod:`site`) to call :func:`site.addsitedir` or edit
:data:`sys.path`.
-The :option:`--home` option defines the installation base directory. Files are
+The :option:`!--home` option defines the installation base directory. Files are
installed to the following directories under the installation base as follows:
=============== ===========================================================
@@ -455,12 +455,12 @@ be done with ::
/usr/local/bin/python setup.py install --prefix=/mnt/@server/export
-In either case, the :option:`--prefix` option defines the installation base, and
-the :option:`--exec-prefix` option defines the platform-specific installation
+In either case, the :option:`!--prefix` option defines the installation base, and
+the :option:`!--exec-prefix` option defines the platform-specific installation
base, which is used for platform-specific files. (Currently, this just means
non-pure module distributions, but could be expanded to C libraries, binary
-executables, etc.) If :option:`--exec-prefix` is not supplied, it defaults to
-:option:`--prefix`. Files are installed as follows:
+executables, etc.) If :option:`!--exec-prefix` is not supplied, it defaults to
+:option:`!--prefix`. Files are installed as follows:
================= ==========================================================
Type of file Installation directory
@@ -472,13 +472,13 @@ data :file:`{prefix}`
C headers :file:`{prefix}/include/python{X.Y}{abiflags}/{distname}`
================= ==========================================================
-There is no requirement that :option:`--prefix` or :option:`--exec-prefix`
+There is no requirement that :option:`!--prefix` or :option:`!--exec-prefix`
actually point to an alternate Python installation; if the directories listed
above do not already exist, they are created at installation time.
Incidentally, the real reason the prefix scheme is important is simply that a
-standard Unix installation uses the prefix scheme, but with :option:`--prefix`
-and :option:`--exec-prefix` supplied by Python itself as ``sys.prefix`` and
+standard Unix installation uses the prefix scheme, but with :option:`!--prefix`
+and :option:`!--exec-prefix` supplied by Python itself as ``sys.prefix`` and
``sys.exec_prefix``. Thus, you might think you'll never use the prefix scheme,
but every time you run ``python setup.py install`` without any other options,
you're using it.
@@ -491,7 +491,7 @@ responsibility to ensure that the interpreter used to run extensions installed
in this way is compatible with the interpreter used to build them. The best way
to do this is to ensure that the two interpreters are the same version of Python
(possibly different builds, or possibly copies of the same build). (Of course,
-if your :option:`--prefix` and :option:`--exec-prefix` don't even point to an
+if your :option:`!--prefix` and :option:`!--exec-prefix` don't even point to an
alternate Python installation, this is immaterial.)
@@ -501,7 +501,7 @@ Alternate installation: Windows (the prefix scheme)
---------------------------------------------------
Windows has no concept of a user's home directory, and since the standard Python
-installation under Windows is simpler than under Unix, the :option:`--prefix`
+installation under Windows is simpler than under Unix, the :option:`!--prefix`
option has traditionally been used to install additional packages in separate
locations on Windows. ::
@@ -509,8 +509,8 @@ locations on Windows. ::
to install modules to the :file:`\\Temp\\Python` directory on the current drive.
-The installation base is defined by the :option:`--prefix` option; the
-:option:`--exec-prefix` option is not supported under Windows, which means that
+The installation base is defined by the :option:`!--prefix` option; the
+:option:`!--exec-prefix` option is not supported under Windows, which means that
pure Python modules and extension modules are installed into the same location.
Files are installed as follows:
@@ -562,7 +562,7 @@ difference between Python and extension modules.)
For example, say you're installing a module distribution to your home directory
under Unix---but you want scripts to go in :file:`~/scripts` rather than
:file:`~/bin`. As you might expect, you can override this directory with the
-:option:`--install-scripts` option; in this case, it makes most sense to supply
+:option:`!--install-scripts` option; in this case, it makes most sense to supply
a relative path, which will be interpreted relative to the installation base
directory (your home directory, in this case)::
@@ -572,7 +572,7 @@ Another Unix example: suppose your Python installation was built and installed
with a prefix of :file:`/usr/local/python`, so under a standard installation
scripts will wind up in :file:`/usr/local/python/bin`. If you want them in
:file:`/usr/local/bin` instead, you would supply this absolute directory for the
-:option:`--install-scripts` option::
+:option:`!--install-scripts` option::
python setup.py install --install-scripts=/usr/local/bin
@@ -932,10 +932,10 @@ Let's examine each of the fields in turn.
to be in Objective C.
* *cpparg* is an argument for the C preprocessor, and is anything starting with
- :option:`!-I`, :option:`-D`, :option:`!-U` or :option:`-C`.
+ :option:`!-I`, :option:`!-D`, :option:`!-U` or :option:`!-C`.
-* *library* is anything ending in :file:`.a` or beginning with :option:`-l` or
- :option:`-L`.
+* *library* is anything ending in :file:`.a` or beginning with :option:`!-l` or
+ :option:`!-L`.
If a particular platform requires a special library on your platform, you can
add it by editing the :file:`Setup` file and running ``python setup.py build``.
@@ -944,20 +944,20 @@ For example, if the module defined by the line ::
foo foomodule.c
must be linked with the math library :file:`libm.a` on your platform, simply add
-:option:`-lm` to the line::
+:option:`!-lm` to the line::
foo foomodule.c -lm
Arbitrary switches intended for the compiler or the linker can be supplied with
-the :option:`-Xcompiler` *arg* and :option:`-Xlinker` *arg* options::
+the :option:`!-Xcompiler` *arg* and :option:`!-Xlinker` *arg* options::
foo foomodule.c -Xcompiler -o32 -Xlinker -shared -lm
-The next option after :option:`-Xcompiler` and :option:`-Xlinker` will be
+The next option after :option:`!-Xcompiler` and :option:`!-Xlinker` will be
appended to the proper command line, so in the above example the compiler will
-be passed the :option:`-o32` option, and the linker will be passed
-:option:`-shared`. If a compiler option requires an argument, you'll have to
-supply multiple :option:`-Xcompiler` options; for example, to pass ``-x c++``
+be passed the :option:`!-o32` option, and the linker will be passed
+:option:`!-shared`. If a compiler option requires an argument, you'll have to
+supply multiple :option:`!-Xcompiler` options; for example, to pass ``-x c++``
the :file:`Setup` file would have to contain ``-Xcompiler -x -Xcompiler c++``.
Compiler flags can also be supplied through setting the :envvar:`CFLAGS`
diff --git a/Doc/library/2to3.rst b/Doc/library/2to3.rst
index ec59679..ace1bfa 100644
--- a/Doc/library/2to3.rst
+++ b/Doc/library/2to3.rst
@@ -41,8 +41,8 @@ It can be converted to Python 3.x code via 2to3 on the command line:
A diff against the original source file is printed. 2to3 can also write the
needed modifications right back to the source file. (A backup of the original
-file is made unless :option:`-n` is also given.) Writing the changes back is
-enabled with the :option:`-w` flag:
+file is made unless :option:`!-n` is also given.) Writing the changes back is
+enabled with the :option:`!-w` flag:
.. code-block:: shell-session
@@ -60,7 +60,7 @@ Comments and exact indentation are preserved throughout the translation process.
By default, 2to3 runs a set of :ref:`predefined fixers <2to3-fixers>`. The
:option:`!-l` flag lists all available fixers. An explicit set of fixers to run
-can be given with :option:`-f`. Likewise the :option:`!-x` explicitly disables a
+can be given with :option:`!-f`. Likewise the :option:`!-x` explicitly disables a
fixer. The following example runs only the ``imports`` and ``has_key`` fixers:
.. code-block:: shell-session
@@ -100,29 +100,29 @@ Since some print statements can be parsed as function calls or statements, 2to3
cannot always read files containing the print function. When 2to3 detects the
presence of the ``from __future__ import print_function`` compiler directive, it
modifies its internal grammar to interpret :func:`print` as a function. This
-change can also be enabled manually with the :option:`-p` flag. Use
-:option:`-p` to run fixers on code that already has had its print statements
+change can also be enabled manually with the :option:`!-p` flag. Use
+:option:`!-p` to run fixers on code that already has had its print statements
converted.
-The :option:`-o` or :option:`--output-dir` option allows specification of an
+The :option:`!-o` or :option:`!--output-dir` option allows specification of an
alternate directory for processed output files to be written to. The
-:option:`-n` flag is required when using this as backup files do not make sense
+:option:`!-n` flag is required when using this as backup files do not make sense
when not overwriting the input files.
.. versionadded:: 3.2.3
- The :option:`-o` option was added.
+ The :option:`!-o` option was added.
-The :option:`!-W` or :option:`--write-unchanged-files` flag tells 2to3 to always
+The :option:`!-W` or :option:`!--write-unchanged-files` flag tells 2to3 to always
write output files even if no changes were required to the file. This is most
-useful with :option:`-o` so that an entire Python source tree is copied with
+useful with :option:`!-o` so that an entire Python source tree is copied with
translation from one directory to another.
-This option implies the :option:`-w` flag as it would not make sense otherwise.
+This option implies the :option:`!-w` flag as it would not make sense otherwise.
.. versionadded:: 3.2.3
The :option:`!-W` flag was added.
-The :option:`--add-suffix` option specifies a string to append to all output
-filenames. The :option:`-n` flag is required when specifying this as backups
+The :option:`!--add-suffix` option specifies a string to append to all output
+filenames. The :option:`!-n` flag is required when specifying this as backups
are not necessary when writing to different filenames. Example:
.. code-block:: shell-session
@@ -132,7 +132,7 @@ are not necessary when writing to different filenames. Example:
Will cause a converted file named ``example.py3`` to be written.
.. versionadded:: 3.2.3
- The :option:`--add-suffix` option was added.
+ The :option:`!--add-suffix` option was added.
To translate an entire project from one directory tree to another use:
diff --git a/Doc/library/ctypes.rst b/Doc/library/ctypes.rst
index 94822ba..b25fbbb 100644
--- a/Doc/library/ctypes.rst
+++ b/Doc/library/ctypes.rst
@@ -1253,7 +1253,7 @@ the library to load.
Try to find a library and return a pathname. *name* is the library name without
any prefix like *lib*, suffix like ``.so``, ``.dylib`` or version number (this
- is the form used for the posix linker option :option:`-l`). If no library can
+ is the form used for the posix linker option :option:`!-l`). If no library can
be found, returns ``None``.
The exact functionality is system dependent.
@@ -1831,7 +1831,7 @@ Utility functions
Try to find a library and return a pathname. *name* is the library name
without any prefix like ``lib``, suffix like ``.so``, ``.dylib`` or version
- number (this is the form used for the posix linker option :option:`-l`). If
+ number (this is the form used for the posix linker option :option:`!-l`). If
no library can be found, returns ``None``.
The exact functionality is system dependent.
diff --git a/Doc/library/gettext.rst b/Doc/library/gettext.rst
index ea439b5..3a87bf5 100644
--- a/Doc/library/gettext.rst
+++ b/Doc/library/gettext.rst
@@ -621,7 +621,7 @@ In this case, you are marking translatable strings with the function
However, you will need to teach your message extraction program to
look for translatable strings marked with :func:`N_`. :program:`xgettext`,
:program:`pygettext`, ``pybabel extract``, and :program:`xpot` all
-support this through the use of the :option:`-k` command-line switch.
+support this through the use of the :option:`!-k` command-line switch.
The choice of :func:`N_` here is totally arbitrary; it could have just
as easily been :func:`MarkThisStringForTranslation`.
diff --git a/Doc/library/warnings.rst b/Doc/library/warnings.rst
index 37f6874..cec55f1 100644
--- a/Doc/library/warnings.rst
+++ b/Doc/library/warnings.rst
@@ -267,13 +267,13 @@ Updating Code For New Versions of Python
Warnings that are only of interest to the developer are ignored by default. As
such you should make sure to test your code with typically ignored warnings
made visible. You can do this from the command-line by passing :option:`-Wd <-W>`
-to the interpreter (this is shorthand for :option:`-W default`). This enables
+to the interpreter (this is shorthand for :option:`!-W default`). This enables
default handling for all warnings, including those that are ignored by default.
To change what action is taken for encountered warnings you simply change what
-argument is passed to :option:`-W`, e.g. :option:`-W error`. See the
+argument is passed to :option:`-W`, e.g. :option:`!-W error`. See the
:option:`-W` flag for more details on what is possible.
-To programmatically do the same as :option:`-Wd`, use::
+To programmatically do the same as :option:`!-Wd`, use::
warnings.simplefilter('default')
diff --git a/Doc/using/cmdline.rst b/Doc/using/cmdline.rst
index 57faf89..7b42da2 100644
--- a/Doc/using/cmdline.rst
+++ b/Doc/using/cmdline.rst
@@ -192,7 +192,7 @@ Miscellaneous options
Issue a warning when comparing :class:`bytes` or :class:`bytearray` with
:class:`str` or :class:`bytes` with :class:`int`. Issue an error when the
- option is given twice (:option:`-bb`).
+ option is given twice (:option:`!-bb`).
.. versionchanged:: 3.5
Affects comparisons of :class:`bytes` with :class:`int`.
@@ -308,7 +308,7 @@ Miscellaneous options
Print a message each time a module is initialized, showing the place
(filename or built-in module) from which it is loaded. When given twice
- (:option:`-vv`), print a message for each file that is checked for when
+ (:option:`!-vv`), print a message for each file that is checked for when
searching for a module. Also provides information on module cleanup at exit.
See also :envvar:`PYTHONVERBOSE`.
diff --git a/Doc/whatsnew/2.0.rst b/Doc/whatsnew/2.0.rst
index 5bd12ba..010a007 100644
--- a/Doc/whatsnew/2.0.rst
+++ b/Doc/whatsnew/2.0.rst
@@ -476,7 +476,7 @@ lost, because benchmarking this is tricky and depends crucially on how often the
program creates and destroys objects. The detection of cycles can be disabled
when Python is compiled, if you can't afford even a tiny speed penalty or
suspect that the cycle collection is buggy, by specifying the
-:option:`--without-cycle-gc` switch when running the :program:`configure`
+:option:`!--without-cycle-gc` switch when running the :program:`configure`
script.
Several people tackled this problem and contributed to a solution. An early
diff --git a/Doc/whatsnew/2.1.rst b/Doc/whatsnew/2.1.rst
index 06366b8..be72bfe 100644
--- a/Doc/whatsnew/2.1.rst
+++ b/Doc/whatsnew/2.1.rst
@@ -692,7 +692,7 @@ of the more notable changes are:
faster than the system :func:`malloc` and have less memory overhead. The
allocator uses C's :func:`malloc` function to get large pools of memory, and
then fulfills smaller memory requests from these pools. It can be enabled by
- providing the :option:`--with-pymalloc` option to the :program:`configure`
+ providing the :option:`!--with-pymalloc` option to the :program:`configure`
script; see :file:`Objects/obmalloc.c` for the implementation details.
Authors of C extension modules should test their code with the object allocator
diff --git a/Doc/whatsnew/2.2.rst b/Doc/whatsnew/2.2.rst
index c4ecb26..d27b937 100644
--- a/Doc/whatsnew/2.2.rst
+++ b/Doc/whatsnew/2.2.rst
@@ -779,8 +779,8 @@ Unicode Changes
Python's Unicode support has been enhanced a bit in 2.2. Unicode strings are
usually stored as UCS-2, as 16-bit unsigned integers. Python 2.2 can also be
compiled to use UCS-4, 32-bit unsigned integers, as its internal encoding by
-supplying :option:`--enable-unicode=ucs4` to the configure script. (It's also
-possible to specify :option:`--disable-unicode` to completely disable Unicode
+supplying :option:`!--enable-unicode=ucs4` to the configure script. (It's also
+possible to specify :option:`!--disable-unicode` to completely disable Unicode
support.)
When built to use UCS-4 (a "wide Python"), the interpreter can natively handle
@@ -979,7 +979,7 @@ New and Improved Modules
output have been corrected. (Contributed by Fred L. Drake, Jr. and Tim Peters.)
* The :mod:`socket` module can be compiled to support IPv6; specify the
- :option:`--enable-ipv6` option to Python's configure script. (Contributed by
+ :option:`!--enable-ipv6` option to Python's configure script. (Contributed by
Jun-ichiro "itojun" Hagino.)
* Two new format characters were added to the :mod:`struct` module for 64-bit
@@ -1140,7 +1140,7 @@ Some of the more notable changes are:
in the main Python CVS tree, and many changes have been made to support MacOS X.
The most significant change is the ability to build Python as a framework,
- enabled by supplying the :option:`--enable-framework` option to the configure
+ enabled by supplying the :option:`!--enable-framework` option to the configure
script when compiling Python. According to Jack Jansen, "This installs a self-
contained Python installation plus the OS X framework "glue" into
:file:`/Library/Frameworks/Python.framework` (or another location of choice).
diff --git a/Doc/whatsnew/2.3.rst b/Doc/whatsnew/2.3.rst
index ebdae69..b909ccd 100644
--- a/Doc/whatsnew/2.3.rst
+++ b/Doc/whatsnew/2.3.rst
@@ -394,7 +394,7 @@ be shared between all three operating systems without needing to convert the
line-endings.
This feature can be disabled when compiling Python by specifying the
-:option:`--without-universal-newlines` switch when running Python's
+:option:`!--without-universal-newlines` switch when running Python's
:program:`configure` script.
@@ -1812,9 +1812,9 @@ pools of memory and then fulfills smaller memory requests from these pools.
In 2.1 and 2.2, pymalloc was an experimental feature and wasn't enabled by
default; you had to explicitly enable it when compiling Python by providing the
-:option:`--with-pymalloc` option to the :program:`configure` script. In 2.3,
+:option:`!--with-pymalloc` option to the :program:`configure` script. In 2.3,
pymalloc has had further enhancements and is now enabled by default; you'll have
-to supply :option:`--without-pymalloc` to disable it.
+to supply :option:`!--without-pymalloc` to disable it.
This change is transparent to code written in Python; however, pymalloc may
expose bugs in C extensions. Authors of C extension modules should test their
@@ -1853,7 +1853,7 @@ Thanks to lots of work by Tim Peters, pymalloc in 2.3 also provides debugging
features to catch memory overwrites and doubled frees in both extension modules
and in the interpreter itself. To enable this support, compile a debugging
version of the Python interpreter by running :program:`configure` with
-:option:`--with-pydebug`.
+:option:`!--with-pydebug`.
To aid extension writers, a header file :file:`Misc/pymemcompat.h` is
distributed with the source to Python 2.3 that allows Python extensions to use
@@ -1879,11 +1879,11 @@ Changes to Python's build process and to the C API include:
* The cycle detection implementation used by the garbage collection has proven
to be stable, so it's now been made mandatory. You can no longer compile Python
- without it, and the :option:`--with-cycle-gc` switch to :program:`configure` has
+ without it, and the :option:`!--with-cycle-gc` switch to :program:`configure` has
been removed.
* Python can now optionally be built as a shared library
- (:file:`libpython2.3.so`) by supplying :option:`--enable-shared` when running
+ (:file:`libpython2.3.so`) by supplying :option:`!--enable-shared` when running
Python's :program:`configure` script. (Contributed by Ondrej Palkovsky.)
* The :c:macro:`DL_EXPORT` and :c:macro:`DL_IMPORT` macros are now deprecated.
@@ -1892,7 +1892,7 @@ Changes to Python's build process and to the C API include:
generally use the :c:macro:`PyAPI_FUNC` and :c:macro:`PyAPI_DATA` macros.
* The interpreter can be compiled without any docstrings for the built-in
- functions and modules by supplying :option:`--without-doc-strings` to the
+ functions and modules by supplying :option:`!--without-doc-strings` to the
:program:`configure` script. This makes the Python executable about 10% smaller,
but will also mean that you can't get help for Python's built-ins. (Contributed
by Gustavo Niemeyer.)
diff --git a/Doc/whatsnew/2.4.rst b/Doc/whatsnew/2.4.rst
index 5fb52fe..42d197e 100644
--- a/Doc/whatsnew/2.4.rst
+++ b/Doc/whatsnew/2.4.rst
@@ -1483,10 +1483,10 @@ Some of the changes to Python's build process and to the C API are:
* Python can now be built with additional profiling for the interpreter itself,
intended as an aid to people developing the Python core. Providing
- :option:`--enable-profiling` to the :program:`configure` script will let you
+ :option:`!--enable-profiling` to the :program:`configure` script will let you
profile the interpreter with :program:`gprof`, and providing the
- :option:`--with-tsc` switch enables profiling using the Pentium's Time-Stamp-
- Counter register. Note that the :option:`--with-tsc` switch is slightly
+ :option:`!--with-tsc` switch enables profiling using the Pentium's Time-Stamp-
+ Counter register. Note that the :option:`!--with-tsc` switch is slightly
misnamed, because the profiling feature also works on the PowerPC platform,
though that processor architecture doesn't call that register "the TSC
register". (Contributed by Jeremy Hylton.)
diff --git a/Doc/whatsnew/2.5.rst b/Doc/whatsnew/2.5.rst
index 093189e..38a2359 100644
--- a/Doc/whatsnew/2.5.rst
+++ b/Doc/whatsnew/2.5.rst
@@ -236,7 +236,7 @@ the repository.
Before a package can be uploaded, you must be able to build a distribution using
the :command:`sdist` Distutils command. Once that works, you can run ``python
setup.py upload`` to add your package to the PyPI archive. Optionally you can
-GPG-sign the package by supplying the :option:`--sign` and :option:`--identity`
+GPG-sign the package by supplying the :option:`!--sign` and :option:`!--identity`
options.
Package uploading was implemented by Martin von Löwis and Richard Jones.
@@ -1639,7 +1639,7 @@ complete list of changes, or look through the SVN logs for all the details.
* The :mod:`webbrowser` module received a number of enhancements. It's now
usable as a script with ``python -m webbrowser``, taking a URL as the argument;
- there are a number of switches to control the behaviour (:option:`-n` for a new
+ there are a number of switches to control the behaviour (:option:`!-n` for a new
browser window, :option:`!-t` for a new tab). New module-level functions,
:func:`open_new` and :func:`open_new_tab`, were added to support this. The
module's :func:`open` function supports an additional feature, an *autoraise*
@@ -2209,7 +2209,7 @@ Port-Specific Changes
* MacOS X (10.3 and higher): dynamic loading of modules now uses the
:c:func:`dlopen` function instead of MacOS-specific functions.
-* MacOS X: an :option:`--enable-universalsdk` switch was added to the
+* MacOS X: an :option:`!--enable-universalsdk` switch was added to the
:program:`configure` script that compiles the interpreter as a universal binary
able to run on both PowerPC and Intel processors. (Contributed by Ronald
Oussoren; :issue:`2573`.)
diff --git a/Doc/whatsnew/2.6.rst b/Doc/whatsnew/2.6.rst
index 4ab1656..f7f03d0 100644
--- a/Doc/whatsnew/2.6.rst
+++ b/Doc/whatsnew/2.6.rst
@@ -2992,7 +2992,7 @@ Changes to Python's build process and to the C API include:
* On Mac OS X, Python 2.6 can be compiled as a 4-way universal build.
The :program:`configure` script
- can take a :option:`--with-universal-archs=[32-bit|64-bit|all]`
+ can take a :option:`!--with-universal-archs=[32-bit|64-bit|all]`
switch, controlling whether the binaries are built for 32-bit
architectures (x86, PowerPC), 64-bit (x86-64 and PPC-64), or both.
(Contributed by Ronald Oussoren.)
@@ -3147,7 +3147,7 @@ Port-Specific Changes: Mac OS X
* When compiling a framework build of Python, you can now specify the
framework name to be used by providing the
- :option:`--with-framework-name=` option to the
+ :option:`!--with-framework-name=` option to the
:program:`configure` script.
* The :mod:`macfs` module has been removed. This in turn required the
diff --git a/Doc/whatsnew/2.7.rst b/Doc/whatsnew/2.7.rst
index 2b0bdf7..3e5d434 100644
--- a/Doc/whatsnew/2.7.rst
+++ b/Doc/whatsnew/2.7.rst
@@ -390,7 +390,7 @@ Here's an example::
args = parser.parse_args()
print args.__dict__
-Unless you override it, :option:`-h` and :option:`--help` switches
+Unless you override it, :option:`!-h` and :option:`!--help` switches
are automatically added, and produce neatly formatted output::
-> ./python.exe argparse-example.py --help
@@ -960,7 +960,7 @@ Several performance enhancements have been added:
benchmark results on 32-bit machines have been mixed. Therefore,
the default is to use base 2**30 on 64-bit machines and base 2**15
on 32-bit machines; on Unix, there's a new configure option
- :option:`--enable-big-digits` that can be used to override this default.
+ :option:`!--enable-big-digits` that can be used to override this default.
Apart from the performance improvements this change should be
invisible to end users, with one exception: for testing and
@@ -1844,12 +1844,12 @@ Consult the :mod:`unittest` module documentation for more details.
The :func:`~unittest.main` function supports some other new options:
-* :option:`-b <unittest -b>` or :option:`--buffer` will buffer the standard output
+* :option:`-b <unittest -b>` or :option:`!--buffer` will buffer the standard output
and standard error streams during each test. If the test passes,
any resulting output will be discarded; on failure, the buffered
output will be displayed.
-* :option:`-c <unittest -c>` or :option:`--catch` will cause the control-C interrupt
+* :option:`-c <unittest -c>` or :option:`!--catch` will cause the control-C interrupt
to be handled more gracefully. Instead of interrupting the test
process immediately, the currently running test will be completed
and then the partial results up to the interruption will be reported.
@@ -1863,7 +1863,7 @@ The :func:`~unittest.main` function supports some other new options:
:func:`~unittest.removeHandler` decorator that can be used to mark tests that
should have the control-C handling disabled.
-* :option:`-f <unittest -f>` or :option:`--failfast` makes
+* :option:`-f <unittest -f>` or :option:`!--failfast` makes
test execution stop immediately when a test fails instead of
continuing to execute further tests. (Suggested by Cliff Dyer and
implemented by Michael Foord; :issue:`8074`.)
@@ -2238,19 +2238,19 @@ Changes to Python's build process and to the C API include:
with ``Py``, or with ``_ctypes``. (Implemented by Thomas
Heller; :issue:`3102`.)
-* New configure option: the :option:`--with-system-expat` switch allows
+* New configure option: the :option:`!--with-system-expat` switch allows
building the :mod:`pyexpat` module to use the system Expat library.
(Contributed by Arfrever Frehtes Taifersar Arahesis; :issue:`7609`.)
* New configure option: the
- :option:`--with-valgrind` option will now disable the pymalloc
+ :option:`!--with-valgrind` option will now disable the pymalloc
allocator, which is difficult for the Valgrind memory-error detector
to analyze correctly.
Valgrind will therefore be better at detecting memory leaks and
overruns. (Contributed by James Henstridge; :issue:`2422`.)
* New configure option: you can now supply an empty string to
- :option:`--with-dbmliborder=` in order to disable all of the various
+ :option:`!--with-dbmliborder=` in order to disable all of the various
DBM modules. (Added by Arfrever Frehtes Taifersar Arahesis;
:issue:`6491`.)
@@ -2397,19 +2397,19 @@ Other Changes and Fixes
renamed, moved, or is accessed through different paths. (Patch by
Ziga Seilnacht and Jean-Paul Calderone; :issue:`1180193`.)
-* The :file:`regrtest.py` script now takes a :option:`--randseed=`
+* The :file:`regrtest.py` script now takes a :option:`!--randseed=`
switch that takes an integer that will be used as the random seed
- for the :option:`-r` option that executes tests in random order.
- The :option:`-r` option also reports the seed that was used
+ for the :option:`!-r` option that executes tests in random order.
+ The :option:`!-r` option also reports the seed that was used
(Added by Collin Winter.)
-* Another :file:`regrtest.py` switch is :option:`-j`, which
+* Another :file:`regrtest.py` switch is :option:`!-j`, which
takes an integer specifying how many tests run in parallel. This
allows reducing the total runtime on multi-core machines.
This option is compatible with several other options, including the
:option:`!-R` switch which is known to produce long runtimes.
(Added by Antoine Pitrou, :issue:`6152`.) This can also be used
- with a new :option:`-F` switch that runs selected tests in a loop
+ with a new :option:`!-F` switch that runs selected tests in a loop
until they fail. (Added by Antoine Pitrou; :issue:`7312`.)
* When executed as a script, the :file:`py_compile.py` module now
diff --git a/Doc/whatsnew/3.0.rst b/Doc/whatsnew/3.0.rst
index a3d3fad..5ecf2eb 100644
--- a/Doc/whatsnew/3.0.rst
+++ b/Doc/whatsnew/3.0.rst
@@ -904,7 +904,7 @@ best strategy is the following:
port from Python 2.x to Python 2.(x+1). Make sure all your tests
pass.
-2. (Still using 2.6:) Turn on the :option:`-3` command line switch.
+2. (Still using 2.6:) Turn on the :option:`!-3` command line switch.
This enables warnings about features that will be removed (or
change) in 3.0. Run your test suite again, and fix code that you
get warnings about until there are no warnings left, and all your
generated by cgit v0.12 at 2024-11-23 18:38:08 (GMT)