mirror of https://github.com/python/cpython
Issue #26638: Merge option warning fixes from 3.6
This commit is contained in:
Martin Panter
commit
92b6154911
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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::
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -1254,7 +1254,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.
|
||||
|
|
@ -1838,7 +1838,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.
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
||||
|
|
|
|||
|
|
@ -1972,7 +1972,8 @@ Loading and running tests
|
|||
methods <deprecated-aliases>` are also special-cased and, when the warning
|
||||
filters are ``'default'`` or ``'always'``, they will appear only once
|
||||
per-module, in order to avoid too many warning messages. This behavior can
|
||||
be overridden using the :option:`-Wd` or :option:`-Wa` options and leaving
|
||||
be overridden using Python's :option:`!-Wd` or :option:`!-Wa` options
|
||||
(see :ref:`Warning control <using-on-warnings>`) and leaving
|
||||
*warnings* to ``None``.
|
||||
|
||||
.. versionchanged:: 3.2
|
||||
|
|
@ -2053,7 +2054,8 @@ Loading and running tests
|
|||
|
||||
The *warnings* argument specifies the :ref:`warning filter <warning-filter>`
|
||||
that should be used while running the tests. If it's not specified, it will
|
||||
remain ``None`` if a :option:`-W` option is passed to :program:`python`,
|
||||
remain ``None`` if a :option:`!-W` option is passed to :program:`python`
|
||||
(see :ref:`Warning control <using-on-warnings>`),
|
||||
otherwise it will be set to ``'default'``.
|
||||
|
||||
Calling ``main`` actually returns an instance of the ``TestProgram`` class.
|
||||
|
|
|
|||
|
|
@ -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')
|
||||
|
||||
|
|
|
|||
|
|
@ -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,11 +308,12 @@ 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`.
|
||||
|
||||
|
||||
.. _using-on-warnings:
|
||||
.. cmdoption:: -W arg
|
||||
|
||||
Warning control. Python's warning machinery by default prints warning
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -758,7 +758,7 @@ Here are the changes 2.2 introduces:
|
|||
operators.
|
||||
|
||||
* Python 2.2 supports some command-line arguments for testing whether code will
|
||||
work with the changed division semantics. Running python with :option:`-Q
|
||||
work with the changed division semantics. Running python with :option:`!-Q
|
||||
warn` will cause a warning to be issued whenever division is applied to two
|
||||
integers. You can use this to find code that's affected by the change and fix
|
||||
it. By default, Python 2.2 will simply perform classic division without a
|
||||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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.)
|
||||
|
|
|
|||
|
|
@ -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.)
|
||||
|
|
|
|||
|
|
@ -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`.)
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ Python 2.6 incorporates new features and syntax from 3.0 while
|
|||
remaining compatible with existing code by not removing older features
|
||||
or syntax. When it's not possible to do that, Python 2.6 tries to do
|
||||
what it can, adding compatibility functions in a
|
||||
:mod:`future_builtins` module and a :option:`-3` switch to warn about
|
||||
:mod:`future_builtins` module and a :option:`!-3` switch to warn about
|
||||
usages that will become unsupported in 3.0.
|
||||
|
||||
Some significant new packages have been added to the standard library,
|
||||
|
|
@ -116,7 +116,7 @@ module has versions with the new 3.0 semantics. Code written to be
|
|||
compatible with 3.0 can do ``from future_builtins import hex, map`` as
|
||||
necessary.
|
||||
|
||||
A new command-line switch, :option:`-3`, enables warnings
|
||||
A new command-line switch, :option:`!-3`, enables warnings
|
||||
about features that will be removed in Python 3.0. You can run code
|
||||
with this switch to see how much work will be necessary to port
|
||||
code to 3.0. The value of this switch is available
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -198,8 +198,8 @@ Other new Python3-mode warnings include:
|
|||
|
||||
* :func:`operator.isCallable` and :func:`operator.sequenceIncludes`,
|
||||
which are not supported in 3.x, now trigger warnings.
|
||||
* The :option:`-3` switch now automatically
|
||||
enables the :option:`-Qwarn <-Q>` switch that causes warnings
|
||||
* The :option:`!-3` switch now automatically
|
||||
enables the :option:`!-Qwarn` switch that causes warnings
|
||||
about using classic division with integers and long integers.
|
||||
|
||||
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue