Yuvgoog Greenle schrieb: > On Mon, Nov 9, 2009 at 11:18 PM, Brett Cannon <[email protected]> wrote: >> First, there is the app user perspective. If I use an application I do >> not need to see any warnings, ever. > > So it comes down to either: > > A. As things are - every ballsy app developer has to have this piece > of code laying around: > import warnings > warnings.filterwarnings("ignore") > > or > > B. we render warnings useless in our every day python lives except for > package buildbots that remember to run with -w (or whatever).
On the contrary, I think that DeprecationWarnings will become much more useful when silenced by default, because people will use them *more*. >From experience, when thinking about emitting DeprecationWarnings in Sphinx, which is a command-line tool, I often don't bother, because *it still works anyway* and I don't want Sphinx users to see a screenful of warnings when just building their docs. If DeprecationWarnings were silenced by default, I (and probably others too) would put them into the code more liberally, because I know that *when* they are displayed, they are displayed to someone who actually *wants* to fix the code that causes them. Of course I could use the "filterwarnings" incantation given above, but that defeats the purpose of the -W command line option, and *globally* silences warnings I don't even want to control. > I would like a demographic on this, but I'm sure that either way > muting warnings will be a devastating blow to the spread of > information about what's new/old in python. Please stop trying to seed FUD. Most Python developers are flexible enough to get to know and use a new and useful tool when they are made aware of it, and using -w is a very simple tool. Georg _______________________________________________ stdlib-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/stdlib-sig
