New in version 3.7.
The Python Development Mode introduces additional runtime checks that are too expensive to be enabled by default. It should not be more verbose than the default if the code is correct; new warnings are only emitted when an issue is detected.
It can be enabled using the
command line option or by setting the
environment variable to 1.
See also
.
Effects of the Python Development Mode
Enabling the Python Development Mode is similar to the following command, but with additional effects described below:
PYTHONMALLOC=debugPYTHONASYNCIODEBUG=1python3-Wdefault-XfaulthandlerEffects of the Python Development Mode:
Add default
. The following warnings are shown:
Normally, the above warnings are filtered by the default
.
It behaves as if the
command line option is used.
Use the
command line option or set the
environment variable to error to treat warnings as errors.
Install debug hooks on memory allocators to check for:
Buffer underflow
Buffer overflow
Memory allocator API violation
Unsafe usage of the GIL
See the
C function.
It behaves as if the
environment variable is set to debug.
To enable the Python Development Mode without installing debug hooks on memory allocators, set the
environment variable to default.
Call
at Python startup to install handlers for the
,
,
,
and
signals to dump the Python traceback on a crash.
It behaves as if the
command line option is used or if the
environment variable is set to 1.
Enable
. For example,
checks for coroutines that were not awaited and logs them.
It behaves as if the
environment variable is set to 1.
Check the encoding and errors arguments for string encoding and decoding operations. Examples:
,
and
.
By default, for best performance, the errors argument is only checked at the first encoding/decoding error and the encoding argument is sometimes ignored for empty strings.
The
destructor logs close() exceptions.
Set the
attribute of
to True.
The Python Development Mode does not enable the
module by default, because the overhead cost (to performance and memory) would be too large. Enabling the
module provides additional information on the origin of some errors. For example,
logs the traceback where the resource was allocated, and a buffer overflow error logs the traceback where the memory block was allocated.
The Python Development Mode does not prevent the
command line option from removing
statements nor from setting
to False.
The Python Development Mode can only be enabled at the Python startup. Its value can be read from
.
Changed in version 3.8: The
destructor now logs close() exceptions.
Changed in version 3.9: The encoding and errors arguments are now checked for string encoding and decoding operations.
ResourceWarning Example
Example of a script counting the number of lines of the text file specified in the command line:
importsysdefmain():fp=open(sys.argv[1])nlines=len(fp.readlines())print(nlines)# The file is closed implicitlyif__name__=="__main__":main()The script does not close the file explicitly. By default, Python does not emit any warning. Example using README.txt, which has 269 lines:
$ python3script.pyREADME.txt 269Enabling the Python Development Mode displays a
warning:
$ python3-Xdevscript.pyREADME.txt 269script.py:10: ResourceWarning: unclosed file <_io.TextIOWrapper name='README.rst' mode='r' encoding='UTF-8'> main()ResourceWarning: Enable tracemalloc to get the object allocation tracebackIn addition, enabling
shows the line where the file was opened:
$ python3-Xdev-Xtracemalloc=5script.pyREADME.rst 269script.py:10: ResourceWarning: unclosed file <_io.TextIOWrapper name='README.rst' mode='r' encoding='UTF-8'> main()Object allocated at (most recent call last): File "script.py", lineno 10 main() File "script.py", lineno 4 fp = open(sys.argv[1])The fix is to close explicitly the file. Example using a context manager:
defmain():# Close the file explicitly when exiting the with blockwithopen(sys.argv[1])asfp:nlines=len(fp.readlines())print(nlines)Not closing a resource explicitly can leave a resource open for way longer than expected; it can cause severe issues upon exiting Python. It is bad in CPython, but it is even worse in PyPy. Closing resources explicitly makes an application more deterministic and more reliable.
Bad file descriptor error example
Script displaying the first line of itself:
importosdefmain():fp=open(__file__)firstline=fp.readline()print(firstline.rstrip())os.close(fp.fileno())# The file is closed implicitlymain()By default, Python does not emit any warning:
$ python3script.py import osThe Python Development Mode shows a
and logs a “Bad file descriptor” error when finalizing the file object:
$ python3-Xdevscript.py import osscript.py:10: ResourceWarning: unclosed file <_io.TextIOWrapper name='script.py' mode='r' encoding='UTF-8'> main()ResourceWarning: Enable tracemalloc to get the object allocation tracebackException ignored in: <_io.TextIOWrapper name='script.py' mode='r' encoding='UTF-8'>Traceback (most recent call last): File "script.py", line 10, in <module> main()OSError: [Errno 9] Bad file descriptoros.close(fp.fileno()) closes the file descriptor. When the file object finalizer tries to close the file descriptor again, it fails with the Badfiledescriptor error. A file descriptor must be closed only once. In the worst case scenario, closing it twice can lead to a crash (see
for an example).
The fix is to remove the os.close(fp.fileno()) line, or open the file with closefd=False.