2017-12-05 21:21 GMT+01:00 Serhiy Storchaka <storch...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
