Raymond Hettinger wrote: > 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. > > 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. > > 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? Hmm, I've checked my sources and found that I am assuming the documented behaviour, ie. the function never fails. The Zope sources also assume this behaviour and many other extensions probably do too... (we really need a repository of available open source code for Python which makes grepping these things easier, oh well). > 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(). -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Apr 16 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 69 days left
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