standardizing the deprecation policy (and how noisy they are)
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. -Brett
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.
This would be my preferred option. Noisy deprecations are annoying for a *lot* of users, but are also useful to quite a lot of other users / developers. 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. All the best, Michael Foord
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.
-Brett _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
On Sun, Nov 08, 2009 at 01:26:59PM -0800, 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).
How about turning warnings on by default in unittest-like situations, and by default have them off at other times? Test running is when they would be most useful, I think. ...then there's the problem of how to decide if we're "test running". --titus -- C. Titus Brown, ctb@msu.edu
On Sun, Nov 8, 2009 at 1:26 PM, Brett Cannon <brett@python.org> 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 <michael@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.) -- --Guido van Rossum (python.org/~guido)
Guido van Rossum wrote:
[snip...] On Sun, Nov 8, 2009 at 1:35 PM, Michael Foord <michael@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.)
Sounds like a good argument. The downside is that code 'just stops working' with no *apparent* warning. Michael -- http://www.ironpythoninaction.com/
Guido van Rossum <guido@python.org> writes:
On Sun, Nov 8, 2009 at 1:35 PM, Michael Foord <michael@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.
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 Mon, Nov 9, 2009 at 12:43 AM, Ben Finney <ben+python@benfinney.id.au<ben%2Bpython@benfinney.id.au>
wrote:
Guido van Rossum <guido@python.org> writes:
On Sun, Nov 8, 2009 at 1:35 PM, Michael Foord <michael@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. [snip]
I learned python from an old book that taught me to raise string exceptions, noisy warnings about deprecation were the only thing that tipped me off that something's wrong. As a newb I would have never executed python with any option at all, no way I would have had enough mileage to hear about such a thing. For me back then, python would have just magically broken on a random day. --yuv
On Sun, Nov 8, 2009 at 13:40, Guido van Rossum <guido@python.org> wrote:
On Sun, Nov 8, 2009 at 1:26 PM, Brett Cannon <brett@python.org> 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 <michael@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.
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
(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.
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. Even better would be some sort of "release mode" argument (e.g. "-R") to python. That could turn off pending deprecation warnings and perhaps other things that fall into a similar category (maybe to allow an app developer to choose between tracebacks or not depending on the value of this flag). Still better if setuptools knew about the release mode so developers would not use it and get the warnings, but people installing it would. I have no idea how this would be done in windows. I'm not offering patches though, so I'll shut up now. Nate
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 ...
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.
Well as I said this helps only if the package has 100% test coverage, such that the developer is sure to exercise all code paths when he/she runs the test suite with warnings explicitly enabled. Besides, as Yuvgoog pointed out, this would not help the casual hobbyist programmer (or professional non-programmer, such as a scientist) who doesn't really have a clue that those warnings exist and are important to check for. Regards Antoine.
On Sun, Nov 8, 2009 at 13:40, Guido van Rossum <guido@python.org> wrote: [SNIP]
On Sun, Nov 8, 2009 at 1:35 PM, Michael Foord <michael@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
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)
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. (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)
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. And, of course, the Python savvy user is perfectly able to report a bug to the application developer.
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.
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? Even /we/ are far from 100% test coverage.
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.
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.
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 think this proposal is totally counter-productive, and counter to the idea that Python caters for diverse categories of developers.
On Mon, Nov 9, 2009 at 1:47 PM, Antoine Pitrou <solipsis@pitrou.net> 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)
Le lundi 09 novembre 2009 à 13:51 -0800, Guido van Rossum a écrit :
On Mon, Nov 9, 2009 at 1:47 PM, Antoine Pitrou <solipsis@pitrou.net> 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)
On Mon, Nov 9, 2009 at 4:55 PM, Antoine Pitrou <solipsis@pitrou.net> 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 <solipsis@pitrou.net> 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
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 <solipsis@pitrou.net> 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)
I'm with Antoine here: I haven't seen a single warning from Python in years... and I do use lots of 3rd party code in projects. To me, this discussion appears a bit artifical. Instead of worrying about too much noise on stderr we should reflect more on whether certain deprecations are useful or not in the first place, e.g. take the md5 module deprecation: It would have been very easy to provide proxy implemenations for the md5 and sha modules, redirecting to the hashlib module, instead of going through the whole deprecation process, forcing developers to clutter up their code with conditional imports and confusing newcomers reading about the md5 module in their Python books. After all, there's a reason why we still have the string module in Python 2.7 without generating any warning whatsoever and properly redirecting to the string methods. IMHO, deprecations are only useful for things that are bound to cause a change which doesn't allow for an option for providing backwards compatible ways of letting older code continue to work with more recent Python releases (even if it gets slower as result of this indirection), e.g. Python syntax changes (such as changes to the except clause) or changes to language semantics (such as integer division). In summary: Don't raise the bar for warning messages, raise the bar for deprecations themsselves. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 09 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Mon, Nov 9, 2009 at 13:47, Antoine Pitrou <solipsis@pitrou.net> 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
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?
Because nobody ran the code with warnings on (or they just ran the test suite and it didn't test all code paths), so that when the Python version removing the deprecated constructs goes out, the library or app is suddenly broken.
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.
I don't know about Ruby but "ruby --help" or "man ruby" should be sufficient, shouldn't it? Looking up command-line options in the bundled documentation is pretty standard, and shouldn't pass as an annoyance.
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.
End users are even less likely to use the command-line under Windows than they are under Linux... Such an option is obviously for power users only, and it is quite reasonable to tell them to use "-Wwhatever" if they want to switch off warnings. Please remember that warnings are /not/ the common situation, they are the exception. Your argument makes it sound like all applications will print out warnings and annoy their command-line users, which is /not/ true.
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.
It is still much better to let people report a bug than to hide the problem until it becomes critical. That's how we help developers; not by making them blind to the issues they may be facing ten months from now.
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.
For me, I usually don't run any third-party app or library using trunk. And if I do, I certainly accept the existence of deprecation warnings; after all, it's better than having the app totally break because of whatever issue ignored by the developers.
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.
Certainly, but that proposal still does not seem to be solving a serious problem. How many people have asked for this to be changed? Do we have regular reports about it on the bug tracker? Or perhaps people are complaining about it on the mailing-lists or on other public fora? Is Python renowned for making the command-line a painful experience? I don't reckon so, but perhaps I've missed something. Bringing such evidence would be helpful, and not only for my own edification :)
[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
On Mon, Nov 9, 2009 at 6:09 PM, Raymond Hettinger <python@rcn.com> wrote:
[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
If they don't care, why does it matter whether they see it or not? Seems like an argument for the status quo. Geremy Condra
[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 6:24 PM, Raymond Hettinger <python@rcn.com> wrote:
[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.
I don't really have a horse in this race one way or the other, but 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. If the warnings exist for a good reason, then they constitute information and should be seen. If they don't, they constitute noise and should be removed.
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.
And thats why you should be able to silence the warnings- which you can currently do, if they bother you so much. To me this seems like a lot of drama over a non-feature. Geremy Condra
On Mon, Nov 9, 2009 at 3:44 PM, geremy condra <debatem1@gmail.com> 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)
On Mon, Nov 9, 2009 at 7:01 PM, Guido van Rossum <guido@python.org> wrote:
On Mon, Nov 9, 2009 at 3:44 PM, geremy condra <debatem1@gmail.com> 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.
Rereading my post I don't see any place where I seem to have argued that deprecation warnings were "really important", but in case that's how it sounded, let me clarify: I don't think this argument is anything other than lots and lots of bikeshedding, since these warnings can already be explicitly silenced by the very people this is designed to protect. Having said that, if you think that deprecation warnings are mostly noise, why not ask the pylint and pychecker devs to handle that and drop the warnings altogether? Geremy Condra
In article <f3cc57c60911091514i43f67896q489adca0585bc460@mail.gmail.com>, geremy condra <debatem1@gmail.com> wrote:
On Mon, Nov 9, 2009 at 6:09 PM, Raymond Hettinger <python@rcn.com> 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
On Mon, Nov 9, 2009 at 6:34 PM, Ned Deily <nad@acm.org> wrote:
In article <f3cc57c60911091514i43f67896q489adca0585bc460@mail.gmail.com>, geremy condra <debatem1@gmail.com> wrote:
On Mon, Nov 9, 2009 at 6:09 PM, Raymond Hettinger <python@rcn.com> 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.
Ok, so whats wrong with just saying import warnings warnings.simplefilter("ignore") and walking away? Geremy Condra
In article <f3cc57c60911100650q551ca79em59d7c47ff61aa5a6@mail.gmail.com>, geremy condra <debatem1@gmail.com> 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
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. (*) All these are developer tools by the way, not end-user apps.
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
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.
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? Regards Antoine.
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 10:38 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
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.
<snip> If you're so worried about the warnings, suppress them. You control the code. Geremy Condra
On Tue, Nov 10, 2009 at 8:50 AM, geremy condra <debatem1@gmail.com> 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)
On Tue, Nov 10, 2009 at 1:19 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Nov 10, 2009 at 8:50 AM, geremy condra <debatem1@gmail.com> 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: "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.". Geremy Condra
geremy condra <debatem1@gmail.com> writes:
On Tue, Nov 10, 2009 at 1:19 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Nov 10, 2009 at 8:50 AM, geremy condra <debatem1@gmail.com> 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 Tue, Nov 10, 2009 at 6:00 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
geremy condra <debatem1@gmail.com> writes:
On Tue, Nov 10, 2009 at 1:19 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Nov 10, 2009 at 8:50 AM, geremy condra <debatem1@gmail.com> 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:
<snip> ...and so he (Antoine) should suppress the warnings if he is worried about the user seeing them. Unless he's operating on an incredibly slow release schedule his users will see his patch a *long* time before they'll see any change in their default version of python's behavior. Geremy Condra
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
In article <1257866927.3579.20.camel@localhost>, Antoine Pitrou <solipsis@pitrou.net> wrote:
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).
Not to belabor the issue, but I don't think that's a good analogy. In the case of a self-signed certificate, I as an end-user do have a decision to make: whether to trust the certificate or not as it may have dire consequences in real life. And I am the only one who can make that policy decision for me. (Plus, the mail application and web browser I use anticipate this use case and provide user interfaces for me to easily evaluate the certificate and to capture my policy decision preference so I'm not pestered when the situation arises again.)
On the other had, having the application break when upgrading to Python N+1 would be critical.
(*) All these are developer tools by the way, not end-user apps.
Roles are relative: I would consider a Mozilla developer to be an end-user of hg. -- Ned Deily, nad@acm.org
On Tue, Nov 10, 2009 at 10:19 AM, Ned Deily <nad@acm.org> wrote:
In article <f3cc57c60911100650q551ca79em59d7c47ff61aa5a6@mail.gmail.com>, geremy condra <debatem1@gmail.com> 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 10 Nov, 2009, at 16:31, geremy condra wrote:
On Tue, Nov 10, 2009 at 10:19 AM, Ned Deily <nad@acm.org> wrote:
In article <f3cc57c60911100650q551ca79em59d7c47ff61aa5a6@mail.gmail.com>, geremy condra <debatem1@gmail.com> 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
Geremy Condra _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
On Tue, Nov 10, 2009 at 10:48 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 10 Nov, 2009, at 16:31, geremy condra wrote:
On Tue, Nov 10, 2009 at 10:19 AM, Ned Deily <nad@acm.org> wrote:
In article <f3cc57c60911100650q551ca79em59d7c47ff61aa5a6@mail.gmail.com>, geremy condra <debatem1@gmail.com> 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 7:31 AM, geremy condra <debatem1@gmail.com> 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. In your proposal, every developer must add a special hack to their code as distribute, which they must disable when they test. 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. -- --Guido van Rossum (python.org/~guido)
On Tue, Nov 10, 2009 at 11:00 AM, Guido van Rossum <guido@python.org> wrote:
On Tue, Nov 10, 2009 at 7:31 AM, geremy condra <debatem1@gmail.com> 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 Nov 10, 2009, at 2:49 PM, geremy condra wrote:
On Tue, Nov 10, 2009 at 11:00 AM, Guido van Rossum <guido@python.org> wrote:
On Tue, Nov 10, 2009 at 7:31 AM, geremy condra <debatem1@gmail.com> 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.
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 :) -- Leonardo Santagada santagada at gmail.com
On Tue, Nov 10, 2009 at 4:02 PM, Leonardo Santagada <santagada@gmail.com> wrote:
On Nov 10, 2009, at 2:49 PM, geremy condra wrote:
On Tue, Nov 10, 2009 at 11:00 AM, Guido van Rossum <guido@python.org> wrote:
On Tue, Nov 10, 2009 at 7:31 AM, geremy condra <debatem1@gmail.com> 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 3:37 PM, geremy condra <debatem1@gmail.com> 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)
On Tue, Nov 10, 2009 at 9:58 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Nov 10, 2009 at 3:37 PM, geremy condra <debatem1@gmail.com> 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
Le lundi 09 novembre 2009 à 15:09 -0800, Raymond Hettinger a écrit :
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.
If it's for single use or for a class project, you are certainly using up-to-date constructs which won't emit any deprecation warning. The issue of deprecation warnings should only appear when you write something that gets used for more than a year or two.
On Mon, Nov 9, 2009 at 11:18 PM, Brett Cannon <brett@python.org> 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
Yuvgoog Greenle schrieb:
On Mon, Nov 9, 2009 at 11:18 PM, Brett Cannon <brett@python.org> 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
On Wed, Nov 11, 2009 at 4:01 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Yuvgoog Greenle schrieb:
On Mon, Nov 9, 2009 at 11:18 PM, Brett Cannon <brett@python.org> 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
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. 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? 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. 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.
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. Georg
On Wed, Nov 11, 2009 at 5:51 PM, Georg Brandl <g.brandl@gmx.net> 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
Brett Cannon <brett@python.org> 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.
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.
It doesn't sit well with the Python Zen admonitions about errors. But I guess warnings aren't errors, so are excluded on that basis. -- \ “Never express yourself more clearly than you are able to | `\ think.” —Niels Bohr | _o__) | Ben Finney
On Tue, Nov 10, 2009 at 12:16 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
Brett Cannon <brett@python.org> 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 Mon, Nov 9, 2009 at 3:09 PM, Yuvgoog Greenle <ubershmekel@gmail.com> wrote:
On Tue, Nov 10, 2009 at 12:16 AM, Ben Finney <ben+python@benfinney.id.au> 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)
On Tue, Nov 10, 2009 at 1:24 AM, Guido van Rossum <guido@python.org> wrote:
On Mon, Nov 9, 2009 at 3:09 PM, Yuvgoog Greenle <ubershmekel@gmail.com> wrote:
On Tue, Nov 10, 2009 at 12:16 AM, Ben Finney <ben+python@benfinney.id.au> 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 Mon, Nov 9, 2009 at 4:13 PM, Yuvgoog Greenle <ubershmekel@gmail.com> wrote:
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).
Thanks Yuval. This puts a much more human face on your posts, which matters to me. A lot, actually.
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!).
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)
On Tue, Nov 10, 2009 at 5:31 AM, Guido van Rossum <guido@python.org> 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
Guido van Rossum <guido@python.org> writes:
On Mon, Nov 9, 2009 at 3:09 PM, Yuvgoog Greenle <ubershmekel@gmail.com> wrote:
On Tue, Nov 10, 2009 at 12:16 AM, Ben Finney <ben+python@benfinney.id.au> 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".
This is all true, and I agree with Guido that care needs to be taken; “Benny” is a diminutive of “Ben”. Overly familiar, unless one knows the person intimately. Yuvgoog Greenle <ubershmekel@gmail.com> writes:
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.
No harm done (in this case I assumed it was a cultural slip). Apology accepted. -- \ “And if I laugh at any mortal thing, / 'Tis that I may not | `\ weep.” —“Lord” George Gordon Noel Byron, _Don Juan_ | _o__) | Ben Finney
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
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.
While deprecation warnings are noisy, I also think it's the best compromise we can think of. Making them silent by default would be worse, except for those very few programs/libraries which have absolutely 100% test coverage. Regards Antoine.
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? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Sun, Nov 8, 2009 at 16:53, Georg Brandl <g.brandl@gmx.net> 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. -Brett
Brett Cannon schrieb:
On Sun, Nov 8, 2009 at 16:53, Georg Brandl <g.brandl@gmx.net> 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
On Mon, Nov 9, 2009 at 11:40, Georg Brandl <g.brandl@gmx.net> wrote:
Brett Cannon schrieb:
On Sun, Nov 8, 2009 at 16:53, Georg Brandl <g.brandl@gmx.net> 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... ;)
OK, fine, I didn't think it through very much when I proposed -W. We can add -w for the same purpose. -Brett
On 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.
DeprecationWarnings are annoying but for good enough reason. I'd rather encourage folks to deal with them sooner rather than later, which is what PendingDeprecationWarnings are for. So I like requiring two (or one is enough for me) releases of PendingDeprecationWarnings, but combined with the requirement that any new warnings be explicitly documented in their own section of the release's What's New doc. That section should also remind you how to enable PendingDeprecationWarnings via the command line and the warnings module itself. I'd also consider adding a PYTHONWARNINGS environment variable to ease toggling of warnings when running Python code via an external script. -- Philip Jenvey
On Nov 8, 2009, at 3: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.
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. -Barry
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 Nov 10, 2009, at 8:45 AM, Antoine Pitrou wrote:
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?
I asked Guido and he has made his call: DeprecationWarning will be silent by default. I have started http://bugs.python.org/issue7319 to track the work. As of right now it has a patch against trunk to add the silencing to the warnings filter by default. Still need to come up with the proper doc changes before it can be committed on trunk and py3k (probably the tutorial and warnings module; anywhere else?). On Sun, Nov 8, 2009 at 13:26, Brett Cannon <brett@python.org> 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.
-Brett
On Sat, Nov 14, 2009 at 03:38, Yuval Greenfield <ubershmekel@gmail.com> wrote:
On Sat, Nov 14, 2009 at 2:23 AM, Brett Cannon <brett@python.org> 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
participants (20)
-
Antoine Pitrou -
Barry Warsaw -
Ben Finney -
Brett Cannon -
C. Titus Brown -
Georg Brandl -
geremy condra -
Guido van Rossum -
Jesse Noller -
Kevin Teague -
Leonardo Santagada -
M.-A. Lemburg -
Michael Foord -
nathan binkert -
Ned Deily -
Philip Jenvey -
Raymond Hettinger -
Ronald Oussoren -
Yuval Greenfield -
Yuvgoog Greenle