On 8 November 2017 at 19:21, Antoine Pitrou <[email protected]> wrote: > On Wed, 8 Nov 2017 11:35:13 +1000 > Nick Coghlan <[email protected]> wrote: > >> On 8 November 2017 at 10:03, Guido van Rossum <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com