On Mon, 6 Nov 2017 at 00:30 Victor Stinner <victor.stinner@gmail.com> wrote:
2017-11-06 8:47 GMT+01:00 Serhiy Storchaka <storchaka@gmail.com>:
> 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.

I like this idea and would argue that `-X dev` should encompass what's proposed for `-X dev=strict` and just have it be strict to begin with. Then we can add an equivalent environment variable and push people who use CI to just blindly set the environment variable in their tests.