(original) (raw)
On Tue, Dec 5, 2017 at 12:10 PM, Victor Stinner <victor.stinner@gmail.com> wrote:
2017-12-05 19:24 GMT+01:00 Guido van Rossum <guido@python.org>:
\>> I disagree that \*users\* of an application is supposed to "handle"
\>> deprecation warnings: report them to the developer, or even try to fix
\>> them. IHMO these warnings (hidden by default) were introduced for
\>> developers of the application.
\>
\> But the whole point of the PEP is that it only warns about deprecations in
\> code over which the user has control -- likely \_\_main\_\_ is their own code,
\> and they \*can\* handle it.
IMHO the core of the PEP 565 is to propose a compromise to separate
"own code" and "external code" (cannot be modified).
I'm unhappy with this suboptimal compromise: "only \_\_main\_\_ is my own
code". Maybe we need something to declare the code that we own, to
enable warnings on them. Just a simple helper on top of
warnings.filterwarnings()? Or maybe I'm already in the "the better is
the enemy of the good" greay area :-)
This is a very good characterization of the dilemma. But IMO we don't have a better proxy for "my own code" (it's tempting to try and define it based on the current directory but this makes too many assumptions about development styles).