Nick Coghlan wrote:
Guido van Rossum wrote:
No, the reason is that if we did this with exceptions, it would be
liable to mask errors; an exception does not necessarily originate
immediately with the code you invoked, it could have been raised by
something else that was invoked by that code. The special value
NotImplemented must pretty much originate directly in the invoked
code, since the implementation guarantees that e.g. a+b can never
*return* NotImplemented: if a.__add__(b) and b.__radd__(a) both return
NotImplemented, TypeError is raised.
That makes sense - although for that reasoning, a TypeError subclass
that the binary operation machinery promotes to a standard TypeError
would seem to work too (with the advantage of also raising at least some
sort of exception when the method is called directly)
I have to correct Guido's explanation a bit: the original reason
for using a special singleton instead of an exception was indeed
a significant difference in performance (raising exceptions at
the Python level is expensive, not so much at the C level).
I don't remember the details, but I did some measurements at
the time which made the decision to use a singleton rather
easy :-)
The NotImplemented singleton was part of the coercion
proposal: http://www.egenix.com/files/python/CoercionProposal.html
(pretty old stuff, now that I look at it again ;-)
That said, Guido's point is just valid. We would have had to
add code that saves the current exception to avoid masking
any pending errors - code like that always turns into a
mess sooner or later.
Cheers,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 10 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
