> This reminds me of an asymmetry between the bool type and other > built-in types: the lack of a __bool__ method. > > Perhaps a __bool__ method should be added to objects, just like > __int__, __str__, __long__, __float__, __complex__ and __unicode__. > > If __bool__ is not defined bool() would fall back to using > __nonzero__ and __len__, just like str() falls back to using > __repr__ when __str__ is not defined. Apart from being a slightly odd name, __nonzero__ does this; I see no reason to rename it to __bool__, since that would add nothing new -- it would only be cosmetics. > Would this be done in CPython with a new tp_bool slot or > special-cased like __unicode__ and __complex__? Binary > compatibility aside, I think it should be a slot. Boolean > evaluation is a pretty basic operation. I think it's actually a bad idea to allow types to define their booleanness independent from their numeric value (for numbers) or length (for containers). --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