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~
--
http://mail.python.org/mailman/listinfo/python-list
