[Python-Dev] PEP 565: Show DeprecationWarning in main (original) (raw)

Victor Stinner victor.stinner at gmail.com
Tue Dec 5 15:43:34 EST 2017

2017-12-05 21:21 GMT+01:00 Serhiy Storchaka <storchaka at gmail.com>:

05.12.17 22:10, Victor Stinner пише:

Maybe we need something to declare the code that we own, to enable warnings on them. Just compare author with the name of the user running a script. ;-)

I was thinking as something like:

enable_warnings_on('app')

which would enable warnings on app.py and app/* including subdirectories (app/tools.py but also app/submodule/thing.py).

But the drawback of this idea compared to PEP 565 is that it requires to modify each application, whereas the PEP 565 changes the default behaviour.

Warnings are a complex beast.

If you think about ResourceWarning: the warning can be emited "in the stdlib", whereas the file was opened in "your own code". ResourceWarning are basically emited anywhere because of their weird nature. It's often that these warnings are emited on a garbage collection, and this can happen anytime, usually far from where the resource was allocated. (Since Python 3.6, if you enable tracemalloc, the ResourceWarning is now logged with the traceback where the resource was allocated!!!)

-b and -bb options are global options to change the behaviour of BytesWarning: it's not possible to only make BytesWarning strict "in your own code".

(I'm not sure neither that all code uses properly the warnings API to identify correctly the caller where the warning should be emitted.)

...

For all these reasons, I prefer to not try to guess what is the "owned code", but simply always emit warnings everywhere :-) That's why I suggest to use -W default option or PYTHONWARNINGS=default (or the new -X dev option or PYTHONDEVMODE=1).

In my experience, it's fine to get warnings in third party code. I'm lucky, I'm only working on open source softwares, so I can report and even fix (!) warnings in the code that I don't own :-)

By the way, if you are annoyed by one very specific warning in external code (which prevents you to fix other warnings "further" in the code), you can ignore it using a filter. You can specify a module name, and even a line number of a module.

https://docs.python.org/dev/library/warnings.html#warnings.filterwarnings

At the end, I'm not sure that the PEP 565 is really needed or would help anyone.

Again, I understand that there is no perfect solution, and that PEP 565 is a compromise.

Victor

More information about the Python-Dev mailing list