[Python-Dev] Boolean transition (original) (raw)

Tim Peters tim.one@comcast.net
Sun, 10 Mar 2002 15:05:23 -0500

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

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.

daysinyear = 365 + isleap(year)

or print [("off", "on")[switch] for switch in switchlist]

Personally, I find those both as obfuscatory workarounds for the lack of a terniary.

Ahem -- I thought we were disparaging my "C bias" here . 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.