On Sun, Nov 8, 2009 at 13:40, Guido van Rossum <gu...@python.org> wrote: [SNIP]
> On Sun, Nov 8, 2009 at 1:35 PM, Michael Foord <mich...@voidspace.org.uk> > wrote: >> Almost no-one is ever going to run Python with PendingDeprecation >> warnings switched on, so there should be at least one 'noisy' release in >> my opinion. > > I disagree. The -3 option is an example of a better approach: silent > by default, warnings enabled by a command line flag. If we can trust > developers to use -3 to check for Py3k incompatibilities, we should > also be able to trust them to check for deprecation warnings > explicitly. > > (Another argument to think about: if you download and install some 3rd > party code, deprecation warnings about that code are *only noise* > since they are not yours to fix. Warnings in a dynamic language work > very different than warnings in a compiled language.) Reflecting upon Guido's comment about compiled languages I have come around to his view and want to make warnings silent by default. Here are my reasons. First, there is the app user perspective. If I use an application I do not need to see any warnings, ever. Just because my interpreter got upgraded (whether explicitly by me, my company's sysadmin, or my OS), that should not suddenly start seeing warnings for some Python-based application I use. We cannot expect all developers to release a new version just before or the day of a new interpreter release. This is what separates interpreted languages from compiled ones; just because you upgrade your compiler does not mean new warnings will suddenly show up for the compiled languages. Now the idea has been floated to solve this by modifying distutils or any other installers to include the line ``-W ignore`` in the shell scripts they install. The problem with this is it assumes all users use the shell script to launch the app. With the introduction of __main__.py support for packages and zipfiles I can easily see people starting to launch apps from the command-line with the newest interpreter they have installed, e.g. ``python2.6 -m someapp``. And just because I have enough knowledge to know how to specify what Python interpreter to use does not mean I care about warnings in Python (might not even know how to program in Python), nor know about the ``-W ignore`` trick (let alone want to have to type that every time I use the app). Second is the perspective of someone not running with the warnings turned on when they need to for tests. Some have said that there is the possibility that they won't have the proper test coverage to pick up the warnings. OK, fine, but that's not our problem. We cannot dictate proper coding practices (nor should we for that leads down the road of Java and checked exceptions). Python has always been about consenting adults. If a development team does not dogfood their own app with warnings turned on then that is their choice and they will be bit in the ass at a later date. If a user gets bit by poor development by a third-party that's unfortunate but once again not our fault since we cannot dictate that people only use quality software. In other words I think having warnings off by default is the best way to improve the situation for users while still empowering developers to know about things they need to change. -Brett _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
