How to pop the interpreter's stack?

[Ethan Furman]

Steven D'Aprano wrote:
> ...
 >
> I think critics of my position have forgotten what it's like to learning 
> the language. One of the most valuable skills to learn is to *ignore 
> parts of the traceback* -- a skill that takes practice and familiarity 
> with the library or function in use. To those who are less familiar with 
> the function, it can be very difficult to determine which parts of the 
> traceback are relevant and which aren't. In this case, the caller has 
> nothing to do with _compile, and the traceback looks like it's an 
> internal bug in a subroutine, when in fact it is actually due to bad 
> input. The experienced developer learns (by trial and error, possibly) to 
> ignore nearly half of the error message in this case.

And it can still be some work to figure out which parts of the traceback 
are relevant, even after a couple years...

> ...
> It need not be that way. This could, in principle, be left up to the 
> developer of the public function to specify (somehow!) that some specific 
> exceptions are expected, and should be treated as coming from public() 
> rather than from some internal subroutine. I don't have a concrete 
> proposal for such, although I did suggest a work-around. I expected 
> disinterest ("I don't see the point"). I didn't expect the level of 
> hostility to the idea that exceptions should (if and when possible) point 
> to the source of the error rather than some accidental implementation-
> specific subroutine. Go figure.

My objection is not to the idea, but to the ad-hoc methods that would 
currently be required.  Resorting to passing exceptions in-band is a 
step backwards.  If python had a way to specify what level an exception 
should be reported from, I might be interested.  At this point, if 
sparing the user one level of traceback was that high a priority to me, 
I would make the validation be either a decorator, or have the 
validation *be* the main routine, and the *real work* routine be the 
private one.

~Ethan~