> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4