- node.warn() for a node-specific warning
- config.warn() for a global non-node specific warning
Each warning is accompanied by a "warning number" so that we can later
introduce mechanisms for surpressing them.
Each warning will trigger a call to pytest_report_warn(number, node, message)
which is by default implemented by the TerminalReporter which introduces
a new option "-rw" to show details about warnings.
small number of changes:
- removed hard-coded links to package release versions, using
a placeholder "latest" instead which is understood by pytest-plugs
- testing against pytest-2.5.2
This changes were implemented so this page only needs
to be updated after pytest releases, not after each package version changes;.
Documented that since pytest 2.4.0 you can use the raw pdb.set_trace() call
directly without the pytest.set_trace() wrapper or explicitly disabling pytest's
output capture using 'py.test -s'.
Clearly stated how pytest (since version 2.0.0.) automatically disables its
output capture when entering an interactive PDB debugger. This avoids confusing
new users because their tests display different output when running with or
without entering an interactive debugger (even if user does nothing in that
interactive debugger session other than exit it and continue with the regular
test execution).
--HG--
branch : pdb_doc_update
If the compared text was in bytes and not actually valid text
(i.e. could not be encoded to text/unicode using the default encoding)
then the assertrepr would fail with an EncodingError. This ensures
that the internal string is always valid unicode, converting any bytes
safely to valid unicode. This is done using repr() which then needs
post-processing to fix the encompassing quotes and un-escape newlines.
This fixes issue 429.
Made it clearer that clearing such references is not mandatory and is only an
optional step which may help the Python interpreter speed up its garbage
collection.
--HG--
branch : document_ExceptionInfo_ref_cycle
pytest.raises() returns an ExceptionInfo object which, if a local reference is
made to it, forms a reference cycle:
ExceptionInfo
--> exception
--> stack frame raising the exception
--> current stack frame
--> current local variables
--> Exception Info
Such a reference cycle would then prevent any local variables in the current
stack frame, or any of its child stack frames involved in the same reference
cycle, from being garbage collected until the next reference cycle garbage
collection phase. This unnecessarily increases the program's memory footprint
and potentially slows it down.
This situation is based on a similar one described in the official 'try'
statement Python documentation for locally stored exception references.
--HG--
branch : document_ExceptionInfo_ref_cycle