[Python-Dev] Boolean transition

[Tim Peters]

[Tim]
> 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.

[Paul Prescod]
> I don't know if that's true or not, but it doesn't seem relevant.

Then you should have the grace to presume I'm not lying <wink>.  It's
relevant only if *why* languages do what they do is interesting to you.  It
is to me.

> 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.

I wouldn't presume to claim what "most languages" do, as I'm only familiar
with a relative handful.

> Here are other languages that (based on some admittedly cursory
> research) treat booleans as entirely distinct from integers:

I don't grasp why this should be interesting, in the absence of their design
rationales.

>  * 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.

I'm only interested in what's most useful.  If I weren't, I'd sure wonder
what the heck garbage collection has to do with this <wink>.

> Methinks your Fortran/C bias shows. ;) And it isn't pretty.

You're arguing for the Fortran approach, and I don't have a C bias:  I first
picked up C very late in my programming life.  The languages I cut my teeth
on do include Fortran Classic, which had a non-numeric "logical" type with
manifest constants .TRUE. and .FALSE.; LISP 1.5, where the empty list "was
true" and all other values "were false"; SNOBOL4, which had no true/false
concept at all ("success" and "failure" drove control flow there); Pascal,
which is "like Fortran" in this respect; and APL, which indeed thrived on
doing arithmetic with 1/0 true/false values.  The only one that was "really
like Python" here was APL.

I liked the APL approach best, simply because it was most useful.  Perhaps
that's because my non-programming background is in discrete mathematics,
where identifying 0/1 with false/true is of great practical value.  For
example, see "Concrete Mathematics" (Knuth, Graham and Patashnik), where
treating a true/false result as 1/0 is so common it's indicated merely by
surrounding a predicate expression with plain square brackets.  This was a
notational advance over the non-programming state of the art (most texts
before CM, including Knuth's TAoCP, use a clumsy Kronecker delta notation).
The programming state of the art would be advanced a little by Guido's PEP,
in my view of the world.

>>     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.

Ahem -- I thought we were disparaging *my* "C bias" here <wink>.  How many
of the languages in your list above have a ternary operator?  Languages that
don't distiguish expressions from statements (like your Scheme example) use
their all-purpose if/else constructs for this, but C introduced "the ternary
wart" for languages that do distinguish.  It got into that mess by departing
from Algol, which also distinguished, but had both statement and expression
forms of if/else.  IMO, C and Pascal both lost by departing from Algol here.

> I don't mind spelling out a terniary as an if/else and I don't mind
> spelling these out either.

Which then looks to me like a clumsy workaround for the lack of treating
false as 0 and true as 1.  We're never going to agree on this, so enough.