[Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Nov 8 15:33:11 EST 2017

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

More information about the Python-Dev mailing list