Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #6769 > unrolled thread

Re: returning NotImplemented

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: returning NotImplemented Ethan Furman <ethan@stoneleaf.us> - 2011-05-31 17:30 -0700

#6769 — Re: returning NotImplemented

Eric Snow wrote:
> Guido indicates earlier in the thread that NotImplemented is used so 
> that you know that it came from the function that you directly called, 
> and not from another call inside that function.  Why does it matter if 
> it came directly from the function or not?  And couldn't the 
> NotImplemented still have come from a call inside the operator, rather 
> than directly?

An exception can bubble up from several levels below the original call. 
  Returning NotImplemented (even if returned from another internal 
function) still has to be deliberately done by the original method.

Later in the thread it is also stated that while exception handling 
performance is not too different in C code, it is very much more 
expensive in Python code.

As to why it would matter if whether the return was from the directly 
called method vs some nested method... not sure, but I would hazard a 
guess that by returning NotImplented the interpreter knows everything 
worked as it should have (assuming no bugs, of course); whereas an 
exception could easily _not_ have come from the directly called method. 
  Imagine if the methods raised exceptions to signal normal behavior, 
and some object was buggy -- for __eq__ we'd end up with a False result, 
instead of getting the exception propagated. (!)

~Ethan~

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web