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

Guido van Rossum guido@python.org
Wed, 16 Apr 2003 09:40:53 -0400

The docs for PyObjectIsTrue() 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 PyObjectNot().

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/)