PEP 285: Adding a bool type

[Bengt Richter]

On Sat, 06 Apr 2002 20:39:41 +0200, Laura Creighton <lac at strakt.com> wrote:

>Mark McEahern writes:
>> [Laura Creighton]
>> > [...]  I am rejecting the existence of booleans in the language
>> > because it is too hard to teach how to use them properly.
>> 
>> How do you use them properly?
>> 
>> Suppose I want to validate users.  I might write something like this:
>> 
>> 	def isValid(user, password):
>> 		if ...:
>> 			return True
>> 		else:
>> 			return False
>
>My pleasure, especially since this is such a cool example.  You have
>just shot yourself in the foot, and do not know it.  When you have
>shipped your isValid function, across the world to your 10,000 clients,
>you will discover this.
>
>Your boss comes in and says, oh, Mark, we need a change to that
>isValid function.  We need to return 3 states, Valid, Invalid, and
>Valid-but-You-Don't-Have-Access-Because-You-Didn't-Pay-Your-Bill.
>
>What do you do now?  
>
>> Using isValid, that returns one of two possible answers, is as clear and
>> bright as day to me.  If later on I want a function that does something
>> different, it would most definitely be named something different.  Why on
>> earth would I want a function named isFoo to return one of more than two
>> possible values?  (Your answer is probably that you never want a function
>> named isFoo.  Hmm, I still don't see why.)
>
>Do you now? Use Booleans when you want to return ON and OFF -- the
>state of that bit in memory, of something that is constrained by
>physical reality, or mathematical reality to only have 2 values, ever,
>cross my heart and the world will end if this ever ceases to be the
>case.  Don't artificially limit yourself to 2 values because your
>vision at the time only extended to 2 values.  The one thing constant
>in this world is change.   If you don't need a third value, somebody 
>else will, later.  Integers are your friends.
>
Classes and objects are even better friends. How do you think we got from DOS errorlevels
to Python exceptions? Magic numbers are out of style ;-)

IANAT, but IMHO, the teaching problems you allude to are not about types themselves,
but about the appropriate use of types to model the problem domain. Your complaint
about isLeap IMHO should be redirected as Kent Seehof suggests. If the Swedish 1712
leap year had two extra days, you can say isLeap is still a valid concept, and can only
be true or false, however that it is an incomplete model of reality for some purposes.
You could say def isLeap(y): return numberOfExtraDays(y)>0 to make the distinctions
clear in one line. From there it's easy to point to the fallacy of 365+isLeap(y)
(and the documentation problem with making any is-someproposition(x) function return
anything but true vs false, however represented).

Frankly, I'm horrified when a teacher prohibits (other than disruptive selfishness).
I'd much rather have the teacher say, solve the problem any way you like, but I have
taught you that some ways often lead to difficulties, so I will demand (a) that you
show you know you are breaking one of my rules of thumb, and (b) that your provide
a rationale for your decision to do so. Just (a) goes a long way towards QA-ing that
they have the idea, and they get to play if they are bright and motivated. An annotated
most-horrible-example-solution may teach more than a spiffy cliche.

If you only have a few acceptable answers, why not just give 'em a multiple choice
test and be done with it? I'd guess it'd be a lot less work than real teaching.

I guarantee you will eventually have a student that is smarter than you are, and who
will surprise (and delight, unless you are ego-deficient) you. Prohibition is a symptom of
management style in the sheep-dip philosopy of teaching, IMHO. Rote patterns are ok
up to a point, but they're plastic flowers vs seeds and bulbs depending on how done.

Regards,
Bengt Richter