Re: [stdlib-sig] standardizing the deprecation policy (and hownoisy they are)
In a message of Mon, 09 Nov 2009 20:03:33 EST, geremy condra writes:
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> wrot e:
the idea that we shouldn't put blinking lights and sirens on the crushomatic 90 00 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.
My point is that 'designing to protect people' is not enough, you need to actually protect them. And while in general 'logically this should protect them' is enough -- (and what intelligent people often mean by 'designing to protect people') -- when it comes to issues of cognative psychology, the important lessons to learn are the ones that teach you is where this one fails ---- by trying to protect X, or at least make it easier for X, you end up making it harder.
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?
I am all for this. And I am all for Marc André's suggestion to raise the barrier for deprecations themselves as well. Laura
Geremy Condra _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
On Mon, Nov 9, 2009 at 8:22 PM, Laura Creighton <lac@openend.se> wrote:
In a message of Mon, 09 Nov 2009 20:03:33 EST, geremy condra writes:
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> wrot e:
the idea that we shouldn't put blinking lights and sirens on the crushomatic 90 00 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.
My point is that 'designing to protect people' is not enough, you need to actually protect them. And while in general 'logically this should protect them' is enough -- (and what intelligent people often mean by 'designing to protect people') -- when it comes to issues of cognative psychology, the important lessons to learn are the ones that teach you is where this one fails ---- by trying to protect X, or at least make it easier for X, you end up making it harder.
I'm having some difficulty reconciling the idea of "protecting" developers from warnings with "we're all adults here" and "errors should never pass silently, unless explicitly silenced". Should I be? Geremy Condra
On Mon, Nov 9, 2009 at 5:41 PM, geremy condra <debatem1@gmail.com> wrote:
I'm having some difficulty reconciling the idea of "protecting" developers from warnings with "we're all adults here" and "errors should never pass silently, unless explicitly silenced". Should I be?
Yes. Warnings are effectively errors that are allowed to pass -- in effect, silently, since users end up silencing them. The "manly" thing to do (to pick an expression popularized by Linus Torvalds) would be to have only errors, and test your code with new Python versions before allowing it to run there. -- --Guido van Rossum (python.org/~guido)
On Mon, Nov 9, 2009 at 9:00 PM, Guido van Rossum <guido@python.org> wrote:
On Mon, Nov 9, 2009 at 5:41 PM, geremy condra <debatem1@gmail.com> wrote:
I'm having some difficulty reconciling the idea of "protecting" developers from warnings with "we're all adults here" and "errors should never pass silently, unless explicitly silenced". Should I be?
Yes. Warnings are effectively errors that are allowed to pass -- in effect, silently, since users end up silencing them.
Ok, so whats the problem with letting them keep silencing them? I don't see how you can get error ennui from warnings you never see.
The "manly" thing to do (to pick an expression popularized by Linus Torvalds) would be to have only errors, and test your code with new Python versions before allowing it to run there.
Lets say I wrestle wolverines in my spare time- are you saying that the warnings should be silent or that there just shouldn't be any? As an aside, given how often the discussion of running on a version you haven't tested comes up, is there a convenience function that raises an error in the event that you're outside of the tested range? Something akin to: def check_version(minimum, maximum): from sys import version_info maximum = tuple(int(x) for x in maximum.split(".")) minimum = tuple(int(x) for x in minimum.split(".")) if not minimum < version_info < maximum: raise RuntimeError("Improper version of Python") Geremy Condra
participants (3)
-
geremy condra -
Guido van Rossum -
Laura Creighton