> > def __repr__(self): > > if self: > > return "True" > > else: > > return "False" > > > > __str__ = __repr__ > > I don't like this: it will break too much code since there > are already two singletons Py_True and Py_False available > in Python and these return 1 / 0 resp. But this is the whole point of introducing a new type rather than simply defining True as 1 and False as 0! > > False = bool(0, _create=1) > > True = bool(1, _create=1) > > Please adjust Py_True and Py_False (at C level) to be > identical to these constants. Yes, that was the intention. > > Issues > > > > Because the repr() or str() of a bool value is different from an > > int value, some code (e.g. doctest-based unit tests) may fail. > > How much of a backwards compatibility problem this will be, I > > don't know. If we find this is a real problem, we could add a > > command-line option to make False and True aliases for 0 and 1 and > > bool an alias for int. > > Please, no ! Agreed -- I just mentioned it as a possibility if we find too much problems due to the new repr() and str(). > Ideal would be to make bool a subtype of int and True and > False two singletons created from 1 and 0 having the bool > type: that's simple and backwards compatible. That's what I am proposing. > One idea for a possible addition: > > Add boolean support to the array module so that it becomes > possible to create arrays of bits. That's an entirely separate issue, and would require major hackery to the array module (if you want the bits to be tightly packed, which I assume you do). Let's not mix it up with this. --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