2017-11-06 8:47 GMT+01:00 Serhiy Storchaka
06.11.17 09:09, Guido van Rossum пише:
I still find this unfriendly to users of Python scripts and small apps who are not the developers of those scripts. (Large apps tend to spit out so much logging it doesn't really matter.)
Isn't there a better heuristic we can come up with so that the warnings tend to be on for developers but off for end users?
There was a proposition to make deprecation warnings visible by default in debug build and interactive interpreter.
The problem is that outside CPython core developers, I expect that almost nobody runs a Python compiled in debug mode. We should provide debug features in the release build. For example, in Python 3.6, I added debug hooks on memory allocation in release mode using PYTHONMALLOC=debug. These hooks were already enabled by default in debug mode. Moreover, applications are not developed nor tested in the REPL. Last year, I proposed a global "developer mode". The idea is to provide the same experience than a Python debug build, but on a Python release build: python3 -X dev script.py or PYTHONDEV=1 python3 script.py behaves as PYTHONMALLOC=debug python3 -Wd -b -X faulthandler script.py * Show DeprecationWarning and ResourceWarning warnings: python -Wd * Show BytesWarning warning: python -b * Enable Python assertions (assert) and set __debug__ to True: remove (or just ignore) -O or -OO command line arguments * faulthandler to get a Python traceback on segfault and fatal errors: python -X faulthandler * Debug hooks on Python memory allocators: PYTHONMALLOC=debug If you don't follow the CPython development, it's hard to be aware of "new" options like -X faulthandler (Python 3.3) or PYTHONMALLOC=debug (Python 3.6). And it's easy to forget an option like -b. Maybe we even a need -X dev=strict which would be stricter: * use -Werror instead of -Wd: raise an exception when a warning is emitted * use -bb instead of -b: get BytesWarning exceptions * Replace "inconsistent use of tabs and spaces in indentation" warning with an error in the Python parser * etc. https://mail.python.org/pipermail/python-ideas/2016-March/039314.html Victor