those darn exceptions

[Chris Angelico]

On Sun, Jun 26, 2011 at 12:28 AM,  <steve+comp.lang.python at pearwood.info> wrote:
> Chris Angelico wrote:
>
>> Sure it can. And KeyboardInterrupt could be raised at any time, too.
>> But this is a TOOL, not a deity. If Function X is known to call
>> Function Y and built-in method Z,
>
> Known by whom? You? Me? The author of X, Y or Z? Everybody? The tool?
>
> How is the tool supposed to know which functions are called? What if it
> doesn't have access to the source code of Y? It might only be available via
> a .pyc file, or it might be written in C, or Fortran, or Java (for Jython),
> or C# (for IronPython).

The idea I was toying with was that it would have the source to X, so
it knows that it calls Y. Unfortunately duck typing makes that
difficult for anything where an object is passed in, but it's at least
possible with simpler calls.

> Who is responsible for ensuring that every time the implementation of *any*
> of X, Y and Z change, the list of exceptions is updated? What do you think
> the chances are that this list will remain accurate after a few years of
> maintenance?

The tool would be run on a snapshot of code. If you update the code,
you rerun it.

> Is this list of exceptions part of the API of function X? Should X be held
> responsible if Z stops raising (say) AttributeError and starts raising
> NameError instead?
>
> Should the *implementation* of X, namely the fact that it calls Y and Z, now
> considered part of the public interface?

Again, not an issue if you don't expect it to be stable. You just look
at how the code functions _now_.

> These are serious questions, not nit-picks. Unless they can be answered
> satisfactorily, this hypothetical tool *cannot exist*. It simply won't
> work. I believe that you might as well be asking for a deity, because the
> tool will need supernatural powers beyond the abilities of ordinary code.

Yep. And because of duck typing, the information isn't really there. I
think you're right that it's impossible.

> And I haven't even raised the spectre of replacing functions (even builtins)
> at runtime, or the use of eval/exec, or any number of other tricks.

Right, but this tool would simply be useless then.

>> and also raises FooException, then
>> X's list of "most likely exceptions" would be FooException +
>> Y.__exceptions__ + Z.__exceptions__.
>
> Even if you somehow, magically, know that X calls Y and Z, you can't draw
> that conclusion. Lists of exceptions don't add like that. Consider:

Again, that would be a limitation of the tool. I'd prefer that it
listed more exceptions than less.

> All this will do is lull people into a false sense of security as they come
> to rely on incorrect and out-of-date information. They'll still be in as
> ignorant a position re exceptions as they are now, only they won't know it.

Yep. Agreed (except for the out-of-date qualifier), and that probably
means this won't be of much use. But hey, it was an interesting
thought experiment.

ChrisA