How to pop the interpreter's stack?

[Ethan Furman]

Carl Banks wrote:
> On Dec 24, 1:24 am, Steven D'Aprano <steve
> +comp.lang.pyt... at pearwood.info> wrote:
>> On Thu, 23 Dec 2010 22:38:05 -0800, Carl Banks wrote:
>>> OTOH, going the extra mile to hide useful information from a user is
>>> asinine. As a user, I will decide for myself how I want to use
>>> implementation-defined information, and I don't want the implementor to
>>> decide this for me. It's bad enough if an implementor fails to provide
>>> information out of laziness, but when they deliberately do extra work to
>>> hide information, that's self-importance and arrogance.
>> But that of course is nonsense, because as the user you don't decide
>> anything of the sort.
> 
> As a user I can criticize the decision of the implementor to
> needlessly filter information, and declare that it's borne out of the
> author's arrogance in thinking he knows what I want when I get a
> traceback.
> 
> I can also opine that Python language shouldn't make it easy for
> library implementors to be arrogant like this.
> 
>> The developer responsible for writing the function
>> decides what information he provides you, starting with whether you get
>> an exception at all, where it comes from, the type of exception, and the
>> error message (if any). Once this information has been passed on to you,
>> you're free to do anything you like with it, but you never get to choose
>> what information you get -- I'm not suggesting any change there. All I'm
>> suggesting is that there should be a way of reducing the boilerplate
>> needed for this idiom:
>>
>> def _validate_arg(x):
>>     if x == 'bad input': return False
>>     return True
>>
>> def f(arg):
>>     if not _validate_arg(arg):
>>         raise ValueError
>>     process(arg)
>>
>> to something more natural that doesn't needlessly expose implementation
>> details that are completely irrelevant to the caller.
> 
> Arrogance.  Who gave you the right to decide what is completely
> irrelevant to user?  I, as the user, decide what's relevant.  If I
> want implementation-dependent information, it's my business.
> 
> I don't want the language to make it easy for arrogant people, who
> think they know what information I want better than I do, to hide that
> information from me.

One of the many things I love about Python is that it stays out of the
way of me getting my work done.  I think a truly pythonic
program/library/module must do the same.  So in this regard I agree with
Carl.

There are also times when I change the exception being raised to match
what python expects from that type of object -- for example, from 
WhatEverException to KeyError for a dict-like object.  So in this regard 
I agree with Steven.

For kj's concern, which seems to be along the lines of functional as 
opposed to custom object, I don't think the traceback should be monkied 
with -- either use a decorator to keep the traceback short, or give the 
_pre_func name a good name and don't worry about it.  I know when I see 
a traceback, I start at the bottom and only work my way up if I need to.

~Ethan~