A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2017-November/150364.html below:

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

[Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoffNick Coghlan ncoghlan at gmail.com
Tue Nov 7 20:35:13 EST 2017
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__

Which says to warn specifically for the __main__ module, and continue
ignoring everything else.

That way ad hoc scripts and the REPL will get warnings by default,
while zipapps and packages can avoid warnings by keeping their
__main__.py simple, and importing a CLI helper function from another
module. Entry point wrapper scripts will implicitly have the same
effect for installed packages.

If folks want to get warnings for other modules as well, then they can
either pass "-Wd" to get warnings for everything, or else enable them
selectively using the default main module filter as an example.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4