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

Nick Coghlan ncoghlan at gmail.com
Tue Dec 5 22:57:39 EST 2017

On 6 December 2017 at 05:11, Barry Warsaw <barry at python.org> wrote:

On Dec 5, 2017, at 13:24, Guido van Rossum <guido at python.org> wrote:

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. I’m not so sure how true that is. I have no sense of the relative popularity of hand crafted dunder-mains vs entry point crafted ones. I know that in my own applications, I tend to use the latter (although pkgresources performance issues bum me out). But then you have applications like pex that use fairly complex hand crafted dunder-mains in their zip files. In either case I don’t want consumers of my applications to have to worry about DeprecationWarnings, since they really can’t do anything about them.

For something like pex, it would likely be appropriate to add the following to main.py:

import sys, warnings
if not sys.warnoptions:
   warnings.simplefilter("ignore")

We don't currently provide that snippet anywhere in the docs, so the PEP suggests we add it: https://www.python.org/dev/peps/pep-0565/#other-documentation-updates

All that to say I really don’t know what the right thing to do here is. All of our fiddling with the reporting of DeprecationWarnings, not to mention PendingDeprecationWarnings and FutureWarnings feels like experimental shots in the dark, and I suspect we won’t really know if PEP 565 will be helpful, harmful, or neutral until it’s out in the wild for a while. I suspect either that what we’re trying to accomplish really can’t be done, or that we really don’t have a good understanding of the problem and we’re just chipping away at the edges.

I'm entirely comfortable with telling app developers "Include this 3 line snippet if you don't want your users to see any warnings by default".

Historically, we've never provided good documentation on how to do that, so apps have tended to rely on the default filters, and we've then had ongoing arguments about who wins and who loses in deciding what the defaults should be.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list