[Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

[Nick Coghlan]

On 8 November 2017 at 19:21, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 8 Nov 2017 11:35:13 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 8 November 2017 at 10:03, Guido van Rossum <guido at python.org> wrote:
>> > OK, so let's come up with a set of heuristics that does the right thing for
>> > those cases specifically. I'd say whenever you're executing code from a
>> > zipfile or some such it's not considered your own code (by default).
>>
>> My current preferred heuristic is just to add a new default filter to the list:
>>
>>     once::DeprecationWarning:__main__
>
> Special cases are not special enough to break the rules.
>
> In other words, I'm -1 on this.  Not only does it add complication and
> inconsistency (bound to catch people by surprise) to an already
> non-trivial set of default warning settings, but it doesn't even solve
> any problem that I'm aware of.  The idea that __main__ scripts should
> get special treatment here is entirely gratuitous.

For interactive use, the principle ends up being "Code you write gives
deprecation warnings, code you import doesn't" (which is the main
aspect I care about, since it's the one that semi-regularly trips me
up when I forget that DeprecationWarning is off by default).

Beyond that, it encourages folks distributing applications for others
to use to keep __main__ simple and import most of their functionality
from other libraries, which I also consider a desirable outcome.

Cheers,
Nick.

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