[Python-Dev] 3-way result of PyObject_IsTrue() considered PITA

[Guido van Rossum]

> The docs for PyObject_IsTrue() promise that the "function 
> always succeeds".  But in reality it can return an error 
> result if an underlying method returns an error.

Then the docs need to be repaired!

> The calls in ceval.c and elsewhere are cluttered and slowed
> by trying to handle all three possibilities.  In other places
> (like bltinmodule.c and pyexpat.c), the result is used directly
> in an "if(result)" clause that ignores the possibility of an
> error return.

Code that ignores the error return possibility is an accident waiting
to happen and should be fixed.

> Instead of fixing the docs, do you guys think there may
> be merit in returning False whenever explicit Truth isn't 
> found?  Favoring practicality over silent error passage?

-1000.  This function may invoke arbitrary Python code; exceptions in
such code should never be silenced.

> This would simplify the use of the function, honor the
> promise in the docs, and match usage in code that had not 
> considered an error result. The function and its callers will 
> end-up a little smaller, a little faster, and a little more consistent.
> Also, reasoning about truth values will be a tad simpler.
> 
> Note, similar thoughts also apply to PyObject_Not().

And a ditto response.


Background: once upon a time the code honored the docs.  This was way
long ago, when comparisons also were not allowed to fail.  This was
found out to be a real bad idea when these operations could be
overloaded in Python, and gradually most code was fixed.
Unfortunately the docs weren't fixed. :-(

--Guido van Rossum (home page: http://www.python.org/~guido/)