On Dec 5, 2017, at 13:24, Guido van Rossum <gu...@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. 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 know that’s unhelpful in deciding whether to accept the PEP or not. In the absence of any clear consensus, I’m happy to trust Guido’s instincts or keep the status quo. -Barry
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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
