Tim Peters wrote:
>
> Java disallowed mixing ints with booleans specifically to stop the
>
> if (x = 1)
>
> flavor of C bug, but Python stops those via a different gimmick.
I don't know if that's true or not, but it doesn't seem relevant.
Python's decision should be independent of it's C heritage so we need to
look not only at why C-derived languages did what they did but also
other languages. Most languages with no C heritage at all have a
non-numeric boolean type. Here are other languages that (based on some
admittedly cursory research) treat booleans as entirely distinct from
integers:
* Scheme
* SML
* JavaScript
* Visual Basic
* Eiffel
* Smalltalk
I'd be curious to hear a list of high level, GC'd languages in the other
camp. Methinks your Fortran/C bias shows. ;) And it isn't pretty.
> ... There's
> nothing reprehensible about, e.g.,
>
> days_in_year = 365 + is_leap(year)
>
> or
>
> print [("off", "on")[switch] for switch in switch_list]
Personally, I find those both as obfuscatory workarounds for the lack of
a terniary. I don't mind spelling out a terniary as an if/else and I
don't mind spelling these out either. Plus the latter can be done more
easily and clearly with a dictionary:
print [{true:"on", false:"off"}[switch] for switch in switch_list]
> Ban sensible uses, and people will just keep using integers for their
> true/false, on/off, set/clear etc values.
If the comparison operators etc. return booleans then people will use
booleans. I'd be amazed if many people avoided them because they wanted
to do tricks like those above. AFAIK, they don't in any of the other
programming languages.
Paul Prescod
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