Guido van Rossum writes:

On Sun, Nov 8, 2009 at 1:35 PM, Michael Foord 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.

That doesn't seem to follow. The Python 2 → Python 3 transition has received a *huge* amount of attention (in the Python world), to the point which pretty much the *only* thing many people know about Python 3 is “it breaks backward compatibility”. So it's not surprising that people are explicitly looking for ways to tell whether their code will break in the transition, and consequently many people using the ‘-3’ flag. I think this is a special case. A transition between minor versions of Python, on the other hand, does not inherently have the same clanging alarm bell associated with it: indeed, by contrast with Python 2 → Python 3, the message is that the upgrade from Python N.M → Python N.M+1 will be a *compatible* upgrade. I would expect consequently far fewer developers go actively looking for compatibility problems.

(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.)

Right, so the users can then pressure the third party to fix their code before it stops working altogether in a future version. When the user complains to the Python community, we can publicly shame the third party into testing and declaring their supported Python versions. After all, they only need to see whether it runs without warnings; they don't even need to remember to turn on any special flags. -- \ “Let others praise ancient times; I am glad I was born in | `\ these.” —Ovid (43 BCE–18 CE) | _o__) | Ben Finney

On Sun, Nov 8, 2009 at 13:40, Guido van Rossum wrote:

On Sun, Nov 8, 2009 at 1:26 PM, Brett Cannon wrote:

...

During the moratorium PEP discussions Guido said he wanted to quiet down deprecation warnings. I see there being two options on this.

One is to keep things as is, but to require two releases with PendingDeprecationWarning so there are three years of silent-by-default warnings to update your code. But that last release before removal came would still be noisy.

The other option is to simply have all warnings filtered out by default. We could alter -W so that when it is used w/o an argument it turns to what is currently the default behaviour (or even turn all warnings which is more than what happens now). This will require that people proactively check for warnings when updating for compatibility, else they will eventually use a Python release where there code will simply break because something changed. This route means we do not have to specify any deprecation policy right now (that would be a separate discussion).

Channeling Guido he is after the latter, but a general discussion would still be good since he didn't explicitly say what he was after other than to quiet down warnings.

I was specifically after all kinds of deprecation warnings, which generally are telling you that you need to make a change in order to remain compatible in the future. That's sometimes interesting but often irrelevant noise. So I would agree with Gregory P Smith's proposal to just treat all deprecation warnings as silent.

There are other kinds warnings which might be useful for other reasons -- they typically point out code that does not do what you might think it does. A good example is the warning added in 2.6 about "assert (x, y)". This is something you ignore at your peril.

On Sun, Nov 8, 2009 at 1:35 PM, Michael Foord 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.

There is also the argument that if people are told they have to explicitly turn on warnings to get them and the switch turns them all on then it might be the case that more people will see and deal with PendingDeprecationWarnings than they do now. The arguments that people will not switch them on is based on current practice. Guido's and Greg's argument is that habits will change such that it is not going to be an issue. What does this mean for the warning filter? It will obviously tone down its need, but would it be needed at all? If warnings are off by default the need to actively filter them out goes down by a lot. And you probably don't want to accidentally filter out a warning if you have to explicitly turn them on. I would argue that if you have to explicitly turn filters on then you don't have much of a need to selectively silence them and thus the filter can just go away.

(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.)

That's very true. Until Mercurial caught up to Python 2.6 the sha/md5 warnings were very annoying. I actually modified my copy to turn them off myself. -Brett

On Nov 8, 2009, at 9:25 PM, nathan binkert wrote:

...

...

(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.)

That's very true. Until Mercurial caught up to Python 2.6 the sha/md5 warnings were very annoying. I actually modified my copy to turn them off myself.

+1 for making warnings silent unless asked for. There is a time when I'm in "migration and maintenance mode" when I want to see these warnings and fix them. When I'm not in this mode, deprecation warnings are like some annoying co-worker who stops by every 15 minutes with a super trivial questions to which you respond, "Go away, do a Google search for the answer!" The nagging of seeing deprecations all the time doesn't make me want to fix the deprecations even more, but tends to have the reverse effect. Maybe a flaw in myself, but quite a common one in humans I think :P

I too find this sort of thing very annoying. Perhaps we should teach people to install their programs with #!/usr/bin/python -W ignore

This way pending deprecations are on by default, but people that install programs will not have them.

Hey, I'd never thought of this before. I'd still rather reverse it, and teach people how to install with warnings enabled. For those installing scripts with Buildout, you can use "initialization = sys.warnoptions = ['ignore']" to silence warnings. Here's a Buildout with the necessary configuration for "silent" Mercurial install (not that a silent install is necessary ATM, but it would "protect" you if a future release re-introduced new deprecation warnings ...): [buildout] parts = mercurial [mercurial] recipe = zc.recipe.egg eggs = mercurial entry-points = hg=mercurial.dispatch:run initialization = sys.warnoptions = ['ignore'] Speaking of, I need to submit a patch to mercurial so that the command- line entry point is specified. But like seeing deprecation warnings in third-party code, it's always a big chasm to approach some project which you have no involvement in (and need to determine if fixes are done on a mailing list, personal e-mail, issue tracker, etc.) for such a trivial fixes as entry points and deprecation warnings ...

On Sun, Nov 8, 2009 at 13:40, Guido van Rossum wrote: [SNIP]

On Sun, Nov 8, 2009 at 1:35 PM, Michael Foord 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

On Mon, Nov 9, 2009 at 1:47 PM, Antoine Pitrou wrote:

(have you ever launched a Gnome or KDE app from the command-line? they can spout *tons* of warnings)

Yes, this is a perfect example of what I *don't* want to happen. I sometimes have to invoke these apps from the command line (seeing no other choice) and I will *not* read the warnings no matter what they say, since I cannot do anything about them. -- --Guido van Rossum (python.org/~guido)

On Mon, Nov 9, 2009 at 4:55 PM, Antoine Pitrou wrote:

Le lundi 09 novembre 2009 à 13:51 -0800, Guido van Rossum a écrit :

...

On Mon, Nov 9, 2009 at 1:47 PM, Antoine Pitrou wrote:

...

(have you ever launched a Gnome or KDE app from the command-line? they can spout *tons* of warnings)

Yes, this is a perfect example of what I *don't* want to happen.

But it doesn't. Most Python applications display at worse one or two deprecation warnings, which is perfectly bearable. (the exception is -3, and that's why it's good to have it opt-in rather than opt-out)

No. It's not. Here's an example - brand new python hacker I know is using third party libraries in his app. He runs that app hundreds of times a day, and gets 3-4 deprecation warnings every time he runs that application. At first I told him to ignore it - then he showed me the logs from the app which were rife with them. I gave him the snippet of code to filter them out pretty quickly. jesse

On Mon, Nov 9, 2009 at 13:47, Antoine Pitrou wrote:

...

First, there is the app user perspective. If I use an application I do not need to see any warnings, ever.

But most end users don't launch their applications via the command-line, so they won't get to see any stderr warnings anyway. (have you ever launched a Gnome or KDE app from the command-line? they can spout *tons* of warnings)

No, I haven't since I am a Mac user. But when I have launched Mac apps from the command-line I have not had issues with warnings. Plus I do launch plenty of command-line apps that could output warnings but typically don't (but as I have said, this is not always the case when I use a new interpreter on an app, e.g. Mercurial under 2.6 the day Python 2.6 was released).

...

We cannot expect all developers to release a new version just before or the day of a new interpreter release.

And that's precisely why deprecation warnings are necessary to warn them beforehand. If you silence deprecation warnings by default, developers /will/ end up in situations where they have to do an emergency release to support the latest Python interpreter.

I don't quite follow that. If they hit deprecation warnings on a new release and warnings are silent by default, how does that force an emergency release? They just found out that the NEXT release of Python will cause them trouble, not the new one that just came out.

(OTOH, noisy deprecation warnings, however annoying they may be to you, don't force developers to do an emergency release in order to fix them; they allow developers to take their time)

Right, while I have to put up with them. As a user I don't want that. If a Ruby app was spitting warnings out I would have to be searching Google on how to turn them off and that's annoying.

...

 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``.

Uh? These would be pretty advanced users. The "-m" option is certainly not known let alone used by the average non-Python savvy user.

At the moment. I know Paul Moore has said he wished more apps were released this way as it is much easier to launch command-line apps that way on Windows. Plus I released a zip file of an app like this and have not had issues.

And, of course, the Python savvy user is perfectly able to report a bug to the application developer.

But reporting a bug is not going to turn the warnings off. They still have to be savvy enough to know to switch them off.

...

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).

This sounds really sophistic. If you know about "-m", you know to type "python --help" which immediately will give you the list of available options, including a possible "-W ignore", "-w" or whatever is added to that purpose.

Not if you are simply told "run this code using -m". And would you really want to have to type ``-W ignore`` every time you ran an app? I sure don't.

...

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.

How condescending is that?

IMO it's not not meant to be. Sorry if you read it that way.

Even /we/ are far from 100% test coverage.

I never claimed we had 100% coverage. But I would expect us all to be running off of trunk for some things with warnings turned on.

...

Python has always been about consenting adults.

Being consenting adults, however, does not mean giving people a gun to shoot themselves in the foot, or removing any useful feature which might let them know that their code should be fixed. We may not be Java, but neither are we C++ or C.

This is obviously coming down to difference of opinion. I don't view switching warnings off by default as shooting anyone in the foot. I put it on the same level as making sure you have unit tests; it's just part of your testing and verification process that your users just don't need to know about.

...

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.

Brett, Python is a rich and diverse ecosystem. We as core developers may live in an ideal world where perfect development practices are followed (and even that is a lie, since we don't have 100% test coverage, some of our tests are flaky and our buildbots are often red), but our software is used in many situations, including by people (scientists, teachers, system administrators, webmasters) who are not professional Python programmers.

I know that. One of my best friends is a neurobiology PhD and they use Python in her lab. They are not expert programmers. But if something broke one day because they got a traceback which could have been avoided had they turned on warnings I would hope they can figure out how to fix that. Otherwise, warnings or not, they have bigger issues to deal with.

...

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.

Actually, it doesn't make the situation significantly better for users, or even for developers, it just satisfies our own little egoistical comfort as power users who don't like the annoying sight of warnings in a terminal.

I obviously disagree.

I think this proposal is totally counter-productive, and counter to the idea that Python caters for diverse categories of developers.

Obviously we both are not about to change our minds on this one as we are coming from different perspectives. So I agree that we disagree and I am happy to leave it at that. -Brett

[Brett Cannon]

This is obviously coming down to difference of opinion. I don't view switching warnings off by default as shooting anyone in the foot. I put it on the same level as making sure you have unit tests; it's just part of your testing and verification process that your users just don't need to know about.

Nice summary. FWIW, I concur with Brett. No one needs to see warnings/deprecations except for the developer who controls the code. Even that developer may only need to see it at one point during the development process. Further, the developer controlling the code just may not care -- the script can be for single use, for a class project, or some other purpose that doesn't require being notified of what may change in a later version of Python. Raymond

[Raymond]

. Further, the developer controlling the code just may not care -- the script can be for single use, for a class project, or some other purpose that doesn't require being notified of what may change in a later version of Python.

[Geremy Condra debatem1@gmail.com]

If they don't care, why does it matter whether they see it or not?

There is a difference about not caring about the content of the warning versus caring about whether the messages clutter the screen. Noise is always bad. There are legitimate reasons for not being interested in what is going to change in a future version of Python -- for those people, the messages are a distraction and nuisance. Raymond

On Mon, Nov 9, 2009 at 3:44 PM, geremy condra wrote:

the idea that we shouldn't put blinking lights and sirens on the crushomatic 9000 because people might eventually ignore them doesn't strike me as being all that smart.

I'm sorry, but you're really not getting the point. The crushomatic already *has* a blinking light and a siren and everyone is *already* ignoring them, because they go off all the time, whenever a person gets closer than 6 feet. So we have no way to warn them when there *really* is a danger, like when a person is about to put their hand into the blender. The solution is to make the machine less dangerous (e.g. if you open the lid the motor is cut off), not to argue that the siren is really important. -- --Guido van Rossum (python.org/~guido)

In article , geremy condra wrote:

On Mon, Nov 9, 2009 at 6:09 PM, Raymond Hettinger wrote:

...

Nice summary.  FWIW, I concur with Brett.  No one needs to see warnings/deprecations except for the developer who controls the code. Even that developer may only need to see it at one point during the development process.  Further, the developer controlling the code just may not care -- the script can be for single use, for a class project, or some other purpose that doesn't require being notified of what may change in a later version of Python.

+1

If they don't care, why does it matter whether they see it or not? Seems like an argument for the status quo.

Because, as it stands in the case of third-party packages, the deprecation warnings target the wrong audience, the end-users. At best the status quo behavior is a constant annoyance and, at worst, encourages end users to learn to ignore them, even in cases where it might eventually matter in their own code. -- Ned Deily, nad@acm.org

In article , geremy condra wrote:

Ok, so whats wrong with just saying

import warnings warnings.simplefilter("ignore")

and walking away?

If the package is a stand-alone application (c.f. Barry's bzr example), it's not reasonable to ask end users to modify its code; they may not even be able to easily (i.e. root privileges required). More generally, it seems unfair and unwise to ask the 10 000 users of a package to take action when ultimately the 1 maintainer of the package is the one who needs to do so. -- Ned Deily, nad@acm.org

On 10 Nov, 2009, at 16:28, Antoine Pitrou wrote:

...

If the package is a stand-alone application (c.f. Barry's bzr example), it's not reasonable to ask end users to modify its code; they may not even be able to easily (i.e. root privileges required). More generally, it seems unfair and unwise to ask the 10 000 users of a package to take action when ultimately the 1 maintainer of the package is the one who needs to do so.

That's why it is advised to report the problem to the maintainer (or perhaps the packager, in case e.g. of a linux distro), like you do for any other bug.

It should be stressed again that it is not a very common problem (how many Python apps do you routinely launch from the command-line, apart from hg, bzr, buildout & friends? (*)), and it's not a critical one either (you can perfectly live with it, like you can live with the occasional warning about a self-signed HTTPS certificate). On the other had, having the application break when upgrading to Python N+1 would be critical.

A significant part of the code I write are command-line tools for system administrators. When they see the deprecation warnings they ignore them at best, and at worst get the impression that Python sucks because of these (to them) annoying messages. As Brett and others noted DeprecationWarnings are useful for the developer of a module, not for their end-users. Unlike to compiled languages end-users get to see Python's Deprecation warnings.

(*) All these are developer tools by the way, not end-user apps.

Why is that relevant? Bzr and hg are not only for Python developers, they can just as well be used for other code or even configuration files. I know that I get annoyed by "random" messages from Java tools that I use, which doesn't help improve my opinion of that language. Ronald

_______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig

On 10 Nov, 2009, at 16:55, Antoine Pitrou wrote:

...

Why is that relevant? Bzr and hg are not only for Python developers, they can just as well be used for other code or even configuration files.

It is relevant because developers (of Python or not) should understand that warning messages are a necessary evil in order to warn of a potential pitfall. In other words, there's no reason for a sensible developer to be angered by the sight of warning messages when using a developer-oriented tool. And, similarly, a system administrator editing configuration files knows that warning messages exist for a reason.

That doesn't make warnings for code that I have no control over any less annoying. And worse, DeprecationWarnings aren't even something that require immediate followup because nothing is broken. It's not, "I installed Python 2.6 and now my tools no longer work", but "I installed Python 2.6 and am now getting useless crap when I run tools".

...

I know that I get annoyed by "random" messages from Java tools that I use, which doesn't help improve my opinion of that language.

Why does it impact your opinion of Java, rather than your opinion of the developers who did nothing to fix the problem in their package? (of course, the deprecation themselves are perhaps mistaken, see Marc-André's message about that)

As the user of a Python package, don't you want to know that your current version of a package may break when you switch to Python N+1? Do you prefer the pleasant surprise of discovering it after the fact?

That's why I test before upgrading a production machine. Running without DeprecationWarnings is not a perfect predicator for running on a future version of Python. Furthermore, I get DeprecationWarnings the day I install Python N, even though Python N+1 is still a long time away (18 months on average). Ronald

Regards

Antoine.

_______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig

On Tue, Nov 10, 2009 at 8:50 AM, geremy condra wrote:

If you're so worried about the warnings, suppress them. You control the code.

No. The nuisance of warnings is that they are presented to the *user*, not the developer, and the user (in many cases) doesn't control the code. -- --Guido van Rossum (python.org/~guido)

geremy condra writes:

On Tue, Nov 10, 2009 at 1:19 PM, Guido van Rossum wrote:

...

On Tue, Nov 10, 2009 at 8:50 AM, geremy condra wrote:

...

If you're so worried about the warnings, suppress them. You control the code.

No. The nuisance of warnings is that they are presented to the *user*, not the developer, and the user (in many cases) doesn't control the code.

-- --Guido van Rossum (python.org/~guido)

In this case, however, he does, as per his comment:

Antoine (“he”, in your sentence) does. *The user does not*, and it is the user who is seeing the warnings:

"A significant part of the code I write are command-line tools for system administrators. When they see the deprecation warnings they ignore them at best, and at worst get the impression that Python sucks because of these (to them) annoying messages.".

-- \ “You can be a victor without having victims.” —Harriet Woods | `\ | _o__) | Ben Finney

On Nov 10, 2009, at 1:28 PM, Antoine Pitrou wrote:

That's why it is advised to report the problem to the maintainer (or perhaps the packager, in case e.g. of a linux distro), like you do for any other bug.

So what you are saying is that all python app developer should receive hundreds of bug reports (or at least "me too" comments) for months if he decides that he has other priorities than to fix deprecation warnings? There is a reason it takes more than a year to remove something from the language and that is so that people can adapt on their own time, so you are either saying that users should ignore errors (giving way to Laura's argument) or that they should be bullied by its users. Or are you suggesting that the default should be warnings on and everyone should release their software with code to turn it off? If I could vote I would be +1 on the idea of warnings off and moving that to pylint or some other tool, but with a good paragraph or two on the docs about it. Or a switch to turn warnings on with an api so that unittest and py.test could turn them on. -- Leonardo Santagada santagada at gmail.com

On Tue, Nov 10, 2009 at 10:19 AM, Ned Deily wrote:

In article ,  geremy condra  wrote:

...

Ok, so whats wrong with just saying

import warnings warnings.simplefilter("ignore")

and walking away?

If the package is a stand-alone application (c.f. Barry's bzr example), it's not reasonable to ask end users to modify its code; they may not even be able to easily (i.e. root privileges required).  More generally, it seems unfair and unwise to ask the 10 000 users of a package to take action when ultimately the 1 maintainer of the package is the one who needs to do so.

--  Ned Deily,  nad@acm.org

Let me rephrase- I'm not asking end users to silence them, I'm saying that if it annoys the end users so much, the devs should do it themselves. Geremy Condra

On Tue, Nov 10, 2009 at 10:48 AM, Ronald Oussoren wrote:

On 10 Nov, 2009, at 16:31, geremy condra wrote:

...

On Tue, Nov 10, 2009 at 10:19 AM, Ned Deily wrote:

...

In article ,  geremy condra  wrote:

...

Ok, so whats wrong with just saying

import warnings warnings.simplefilter("ignore")

and walking away?

If the package is a stand-alone application (c.f. Barry's bzr example), it's not reasonable to ask end users to modify its code; they may not even be able to easily (i.e. root privileges required).  More generally, it seems unfair and unwise to ask the 10 000 users of a package to take action when ultimately the 1 maintainer of the package is the one who needs to do so.

--  Ned Deily,  nad@acm.org

Let me rephrase- I'm not asking end users to silence them, I'm saying that if it annoys the end users so much, the devs should do it themselves.

How do I do that for the libraries I distribute? Users of my libraries should not get DeprecationWarnings about my code, but I should be able to generate DeprecationWarnings of my own when I deprecate some of my APIs. Oh, and it should still be possible for me to check for DeprecationWarnings in my code.

Ronald

http://docs.python.org/3.1/library/warnings.html#module-warnings Its a pretty well thought out interface, actually. In the cases you mention (obviously without looking at your code) I'd suggest that you subclass warning and filter based on that. Geremy Condra

On Tue, Nov 10, 2009 at 11:00 AM, Guido van Rossum wrote:

On Tue, Nov 10, 2009 at 7:31 AM, geremy condra wrote:

...

Let me rephrase- I'm not asking end users to silence them, I'm saying that if it annoys the end users so much, the devs should do it themselves.

So either way the developers must be aware of the warnings.

I don't understand how default suppressing all warnings implies that a developer "must" be aware of them.

In your proposal, every developer must add a special hack to their code as distribute, which they must disable when they test.

You only need the "special hack" (I'd point out that its in the standard library docs) if you're running deprecated code. Leave it off until a warning comes up, then decide what you're going to do about the warning, then suppress it. The important thing was that you were made aware of the problem and then made a conscious decision to do something about it, rather than being totally unaware of the problem until it became an error. That's no better than no warnings at all.

In my proposal, developers must explicitly run with some flag (e.g. -w) when they test. The burden for the developer is about the same in the case of a conscientious developer, while in your proposal lazy developers place the burden on their users. I really don't see how your proposal is better.

1) I'd see the burden of typing python -w every time I tested, or changing the #! on my test code and breaking it on 3.1 and back, as being much larger than the burden of typing fifty characters once. 2) a lazy developer probably isn't paying attention to warnings because he has no intention of fixing them before they blow up. I'm pretty sure that's not a development habit that should be well supported by Python. 3) As I've said before, if you don't think the warnings are important info, then ask pylint and pychecker to take them up and take them out of Python. That's the case where there isn't any burden on either the conscientious dev or the end user. Geremy Condra

On Tue, Nov 10, 2009 at 4:02 PM, Leonardo Santagada wrote:

On Nov 10, 2009, at 2:49 PM, geremy condra wrote:

...

On Tue, Nov 10, 2009 at 11:00 AM, Guido van Rossum wrote:

...

On Tue, Nov 10, 2009 at 7:31 AM, geremy condra wrote:

...

Let me rephrase- I'm not asking end users to silence them, I'm saying that if it annoys the end users so much, the devs should do it themselves.

So either way the developers must be aware of the warnings.

I don't understand how default suppressing all warnings implies that a developer "must" be aware of them.

...

In your proposal, every developer must add a special hack to their code as distribute, which they must disable when they test.

You only need the "special hack" (I'd point out that its in the standard library docs) if you're running deprecated code. Leave it off until a warning comes up, then decide what you're going to do about the warning, then suppress it. The important thing was that you were made aware of the problem and then made a conscious decision to do something about it, rather than being totally unaware of the problem until it became an error. That's no better than no warnings at all.

So you are saying that developers should re-release their software when a new python release happens just to put some code to disable warnings? It does take effort to make a software release, and every time you do one is a chance to screw things up (even python had releases issues). For me it is unacceptable.

If its an absolute no-no that warnings be raised then blanket suppress them. The snippet of code from the warnings module should do the job.

...

3) As I've said before, if you don't think the warnings are important info, then ask pylint and pychecker to take them up and take them out of Python. That's the case where there isn't any burden on either the conscientious dev or the end user.

Good that you agree on taking the warnings out of python :)

I think this whole discussion is pointless bikeshedding. My point here is that changing the way python is invoked doesn't strike me as really solving the problem. If you believe that the warnings are the problem, then lobby to have them taken out. If you think the timeline for them is the problem, then change that. If you just want to stop your users from seeing those warnings, but think they're appropriate, then the tools to do that already exist, and I would much prefer that you used them. Geremy Condra

On Tue, Nov 10, 2009 at 9:58 PM, Guido van Rossum wrote:

On Tue, Nov 10, 2009 at 3:37 PM, geremy condra wrote:

...

If its an absolute no-no that warnings be raised then blanket suppress them.

Read the subject line again. It's about deprecation warnings specifically -- not all warnings.

This is my last post on the subject, I don't think I can be any clearer than I already have been.

-- --Guido van Rossum (python.org/~guido)

Then blanket suppress the deprecation warnings: import warnings warnings.simplefilter('ignore', DeprecationWarning) Geremy Condra

On Mon, Nov 9, 2009 at 11:18 PM, Brett Cannon 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). 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. --yuv

On Wed, Nov 11, 2009 at 4:01 AM, Georg Brandl wrote:

Yuvgoog Greenle schrieb:

...

On Mon, Nov 9, 2009 at 11:18 PM, Brett Cannon 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 you don't feel like your users need that information, don't give it to them. Same thing goes for both sphinx and python in general.

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.

Please read the documentation, you can filter what and how you want.

...

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.

But also an unnecessary one. Everything you've described can be done simply and without changing python's behavior. There's just no need to make the change. Geremy Condra

On Wed, Nov 11, 2009 at 5:51 PM, Georg Brandl wrote:

geremy condra schrieb:

...

...

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.

Please read the documentation, you can filter what and how you want.

I don't read the documentation.  I write it.

I'm well aware of your contributions to Python- I simply assumed that since you were insinuating something wasn't possible when the docs made a special point of mentioning that it was, you weren't aware that the capability existed. No offense was intended.

Of course I can filter out only deprecation warnings occurring in a sphinx.* module.  But then the extension author who wants to see them has to change my code so that he can see the warnings again.  That's not easier than running "python -w", is it?

I'd just extend sphinx's -w flag so that if it isn't given a filename it would write to stdout. It also seems likely to me that that change would land on your users machines much sooner than any change to python would, although you would obviously know more about that than I would.

And that's the problem with the warnings being displayed by default: it gives me extra work to figure out what to filter and to add that filter to all my programs, and it gives the user of a program or library extra work to figure out where the warnings are filtered, and to remove that code.

IMHO, thats the idea behind Python emitting warnings at all- that one of the unspoken contracts between the program and Python has been broken in a way that, while not immediately disastrous, will nevertheless eventually end in tears. It is then the developer's responsibility to make sure that the problem has been appropriately resolved, and to write the appropriate (explicit, hopefully narrowly targeted) code to suppress the warning in the event that it *is* superfluous. I'd also like to point out that if you get the same passel of superfluous warnings every time that you run under -w that you do normally, the arguments raised earlier about error ennui become doubly relevant, since now you now have the option of making them 'go play over there' rather than cluttering up your screen.

Even worse, if no warnings are emitted, but would be emitted by default, people probably wouldn't even look for a warnings filter but assume the code is OK. With warnings silenced but activated with a simple -w flag, they *know* they are silent and they can use -w to show them.  Much simpler, much more consistent.

This is the most convincing thing I've heard on this discussion so far. Its a little bit of a consolation prize (sure, we broke your expectations in a way that left you unaware that your code would blow up until it did, but at least we did it consistently!) but assuming that every other option were taken off the table I could understand this being considered a virtue.

...

...

...

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.

But also an unnecessary one. Everything you've described can be done simply and without changing python's behavior. There's just no need to make the change.

There's never a "need" to make any change.  Why introduce "with"?  A simple try-finally is all you need.  Etc.  We make these changes because we think that they benefit our users, make life a bit easier and coding a bit more fun.  Seeing deprecation warnings every time I run hg was no fun at all.

You're right, of course- 'need' is an impossibly high standard to meet in a project as mature as python. The point I was trying to make was that this proposal alters two of the (IMO) most important contracts between developers and python (invocation and error notification), that the bar for such a change should be set pretty high, and that I don't think that things that can be easily accomplished inside of the standard library should be seen as meeting that standard. Again, YMMV. Geremy Condra

On Tue, Nov 10, 2009 at 12:16 AM, Ben Finney wrote:

Brett Cannon writes:

...

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.

This is the most convincing point I see in favour of disabling DeprecationWarning by default. Thanks for clearly stating why it applies only to language interpreter implementations.

Sorry Benny but you were convinced by an invalid argument. This move won't save developers from releasing "a new version just before or the day of a new interpreter release" because things are bound to be deprecated. Developers will have to work extra hard when they find out their app just breaks completely on a sunny interpreter release. No pesky warnings - just plain old traceback and a dead process. Though I do agree with Brett on agreeing to disagree, --yuv

On Tue, Nov 10, 2009 at 1:24 AM, Guido van Rossum wrote:

On Mon, Nov 9, 2009 at 3:09 PM, Yuvgoog Greenle wrote:

...

On Tue, Nov 10, 2009 at 12:16 AM, Ben Finney wrote: [...]

...

Sorry Benny but you were convinced by an invalid argument.

Maybe you know Ben personally and maybe it's different in your culture, but to me it sounds pretty derogatory to call someone "Benny" who signs as "Ben".

(BTW are you using a pseudonym? Yuvgoog sounds like a made-up name. While we are talking about how to address people, I just had to ask.)

...

No pesky warnings - just plain old traceback and a dead process.

Have you actually ever tried to debug a warning? Typically the easiest thing to do is to turn warnings into errors so you can see exactly where it comes from...

-- --Guido van Rossum (python.org/~guido)

First of all I'd like to apologize to Ben, this may sound like a lame excuse but I guess Ben Finney somehow turned into Benny because of my lack of sleep. So again sorry for that, I really didn't mean it that way. Yuvgoog is a pseudonym indeed, my real name is Yuval Greenfield. I'd grown a habit of trying to see where I get spam mail from so I use names mangled with the service name. You might see me as Yuvpic Greenasa, Yuvfaceal Greenbookfield, etc. I guess this habit's one I should get rid of, especially seeing as it really hasn't paid off (I haven't caught a single spammer yet after probably 6 years of it). Concerning debugging warnings, I have to say I currently remember my experience with 2: the deprecation of sets and the deprecation of string exceptions. On both occasions the warnings helped me figure things out before my code broke. Specifically with raising string exceptions, warnings saved me and my colleagues from alot of bad code, string exceptions were the convention at my office and I only found out early because I installed a new python that warned me. Finding this out as an error might not have been too bad either but it would have probably taken more time until I got a python that doesn't allow raising strings (2.6!). --Yuval Greenfield (yuv)

On Tue, Nov 10, 2009 at 5:31 AM, Guido van Rossum wrote: [snip]

In the balance, I think it's easy enough to find these things by using the version that actually breaks things. If you are your only customer, until then, there's little benefit in fixing the warnings ahead of time (except perhaps for learning -- but, strangely, there are ways of learning about programming besides trying things out :-). If you have other customers, you should get used to testing with the latest version of Python anyway -- running without warnings in a previous version really isn't a good enough test for future compatibility.

-- --Guido van Rossum (python.org/~guido)

Yeah, it's easy to find and fix the bugs using the version that incurs them. I'm not worried about that, I'm more worried about how information will spread, a lot of pythonistas I know won't learn about deprecations until their program is broken. Deprecation warnings spread the word more elegantly and faster than hard deprecations IMO. I guess an upside to silent warnings would be that we could have a lot more of them. It could be nice if pylint was integrated as a warning level, lets say with 2 popular conventions in the std-lib. I personally always maximize the warning level on my C compiler and I like the insight. --yuv

On Nov 8, 2009, at 3:40 PM, Guido van Rossum wrote:

I was specifically after all kinds of deprecation warnings, which generally are telling you that you need to make a change in order to remain compatible in the future. That's sometimes interesting but often irrelevant noise. So I would agree with Gregory P Smith's proposal to just treat all deprecation warnings as silent.

+1

There are other kinds warnings which might be useful for other reasons -- they typically point out code that does not do what you might think it does. A good example is the warning added in 2.6 about "assert (x, y)". This is something you ignore at your peril.

Yes, I was quite surprised at the few small example of this in Launchpad. This was actually something I was glad to see warned about, and of course we landed fixes for these independent of our Python 2.6 migration work.

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.

+1

(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.)

Very +1 -Barry

Brett Cannon schrieb:

On Sun, Nov 8, 2009 at 16:53, Georg Brandl wrote:

...

Brett Cannon schrieb:

...

During the moratorium PEP discussions Guido said he wanted to quiet down deprecation warnings. I see there being two options on this.

One is to keep things as is, but to require two releases with PendingDeprecationWarning so there are three years of silent-by-default warnings to update your code. But that last release before removal came would still be noisy.

The other option is to simply have all warnings filtered out by default. We could alter -W so that when it is used w/o an argument it turns to what is currently the default behaviour (or even turn all warnings which is more than what happens now).

As a technical note, optional option arguments are a bad idea.

python -W ignore

Am I calling the file "ignore" with all warnings enabled or running the interactive interpreter ignoring all warnings?

You are calling the file called "ignore"; the argument to -W must contain colons to be valid.

It doesn't need to now; and IMO that is quite helpful, since it allows e.g. a very short -Wi argument without me having to remember just how many colons I have to put there. And even if that change is deemed to be fine, why shouldn't I have colons in my filename? Special cases are not special enough... ;) Georg

I'm probably unable to catch up on this whole thread right now, but having been recently defeated by DeprecationWarnings when attempting to update Launchpad to Python 2.6, I'd say the one thing that would have really helped us is an environment variable tied to -W, e.g $PYTHONWARNINGS. If I could have shut up DeprecationWarnings with one wave of my magic setenv, I think things would have gone much quicker for us.

That's a good point, I think. How about opening a ticket?

On Sat, Nov 14, 2009 at 03:38, Yuval Greenfield wrote:

On Sat, Nov 14, 2009 at 2:23 AM, Brett Cannon wrote:

...

py3k (probably the tutorial and warnings module; anywhere else?).

Maybe all the "what's new" that talk about porting to py3k.

Well, this will be in 2.7 so it won't require specific mention in porting. But it will be covered in "What's New" for 2.7 and 3.2. -Brett