[Python-Dev] PEP 565: Show DeprecationWarning in __main__

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 pkg_resources 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