[Python-Dev] Proposal: go back to enabling DeprecationWarning by default

[Brett Cannon]

On Mon, 6 Nov 2017 at 00:30 Victor Stinner <victor.stinner at gmail.com> wrote:

> 2017-11-06 8:47 GMT+01:00 Serhiy Storchaka <storchaka at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171106/04afa125/attachment-0001.html>