Mark McEahern wrote:
> If, as Fredrik says, there's already one obvious way to return True (and
> that's the int 1), then we already have the problem that people will be
> inclined to compare something to this canonical truth in conditional
> statements.
Actually, he wrote "preferred", not "obvious".
I.e.:
def bool(x): return not not x
will return 0 or 1.
but (), [], "", and None also evaluate as false in a logical
context, while most other things evaluate as true.
Having canonical True and False values would lead newcomers
to compare to them. This would work, for example:
DONE = y and (x > y)
...
if DONE is False:
...
On the other hand, this wouldn't (unless y is a boolean):
DONE = (x > y) and y
...
if DONE is False:
...
Of course, it works either way if you replace "DONE is False"
with "not DONE". Or if you replace "y" with "bool(y)".
Since there aren't canonical True/False values, there is
currently an obvious solution: use "not DONE". But "native"
boolean support will lead to mistakes like this unless you
start taking steps to introduce type-safety with operations
involving boolean values. This is definitely going farther
than was intended by the PEP.
-Jerry
-O Gerald S. Williams, 55A-134A-E : mailto:gsw@agere.com O-
-O AGERE SYSTEMS, 6755 SNOWDRIFT RD : office:610-712-8661 O-
-O ALLENTOWN, PA, USA 18106-9353 : mobile:908-672-7592 O-
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