On Tue, Dec 5, 2017 at 11:11 AM, Barry Warsaw <barry@python.org> wrote:

On Dec 5, 2017, at 13:24, Guido van Rossum <guido@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.

This makes it the responsibility of the pex developers to at least test for deprecation errors in their __main__. I don't know what pex is, but presumably they have some QA and they can test their zips or at least their __main__ with specific Python versions before distributing them. I am confident that it's not going to be a problem for pex developers or users.

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.

I also expect that this PEP will only have a small effect. It is a compromise, but I'm okay with that. There seems to be no way to find out what effect changes in this area will really have, because small-scale experiments where some development team starts paying attention to deprecations don't translate into what it will mean for the large majority who aren't particularly interested in them (but who may still be affected when the deprecations finally take effect and some feature disappears).

The main category of users who are going to be affected are "casual" users -- it's they who have the most code in __main__ files and at the same time have the least idea of where Python is header. Yes, they will occasionally be annoyed. But they will also occasionally be glad that we point out a deprecation to them. And, unlike the situation before Python 2.7, they won't be annoyed by warnings in code they can't update -- they'll get warnings only about their own scripts.

All in all, I think that for professional developers and users of professionally developed Python packages, at worst not much will change and at best there will be some small benefits; while for casual developers and users there will be some benefits and those will outweigh the downsides.

In 5 years or so we can reevaluate.

--Guido van Rossum (python.org/~guido)