PEP 285: Adding a bool type

Laura Creighton lac at strakt.com
Mon Apr 8 11:52:07 EDT 2002


Ken Seehof:

(I agree with everything in his article, and I am snipping it to this point
 because of this.)

> You have repeatedly argued that adding booleans to python is a bad thing
> specifically because it will make it more difficult to change functions
> such as IsRed to return more than two different values.  Well, changing
> IsRed to return more than two different values (without refactoring) is
> always a bad thing.  I don't see what's wrong with making bad things more
> difficult.

No.  This is  where we have a misunderstanding.  this is because of
the isleap function.  You have conceptualized that as 'a function 
that was designed to return a boolean' and therefore think that I want
to encourage people to write functions called issomethings to return
ints so you can extend them to return 3 values.

My understanding of the isleap function came with the baggage of
and Guido wants to let people be able to do arithmetic.  We never
had booleans before.  Therefore my conceptualization of the function
was that it was a function designed to return the integer number
of leap days.  Clearly its designer thinks that this can only be
0 or 1.  Thus its designer gave it the rotten name isleap. I think
both the name is poor and that doing arithmetic on bools is poor.

I think that the function that returns the number of leap days should
not be called isleap, but I fear that anybody who thinks, hah, leap
days are 0 or 1, therefore I should get out a bool, will make this
error.  This error is using a bool for something that can have more
than 2 states to return, confusing 'that this year 1, is a leap
year' with 'we get 1 more day'.  And I have oceans of sympathy for
whatever poor soul did that.  It is only when the function comes
to Sweden that the poor soul will go 'oops'.

> You have also argued that writing yes/no functions without foresight is a
> bad thing.  I agree with you.  And I am in favor of decreasing the total
> number of yes/no functions and variables.  However, I don't see any
> reason to think that adding booleans to python will encourage writing
> more yes/no functions.  This is like the proposition that making condoms
> available causes teenagers to have more sex.

(er, I think that you are claiming that making them available causes
teenagers to think about sex more often, or want sex more, or something
like that, which I think, like you, is foolish.  I sure hope that making 
condoms available causes teenagers to have more sex -- Every teenager who 
wants to have sex, has a willing partner, but doesn't because he or she 
doesn't want a pregnancy and there is no birth control, can now have sex.  
To my mind this is a _big_ _win_.

> In short, here's my advice:
> 
> 1. Do not implement functions or variables with yes/no semantics unless
> you are quite certain that the yes/no semantics are appropriate.  If
> you are a teenager, don't have sex.
> 
> 2. Once you have implemented yes/no semantics, you are committed, until
> you change your model and refactor accordingly.  Always use a condom.
> 
> This advice applies equally whether booleans are part of the language
> or not.  Adding booleans to python has no real effect other than to
> make any commitment to yes/no semantics more clear.  This helps people
> follow both pieces of advice.
> 
> I am glad booleans were added, and I recommend that they should usually
> be avoided.  :-)
> 
> - Ken Seehof


I agree 100% with your recommendation, and actually what I was saying
is that its hard to get students to abide by that recommendation.  It's
a hard recommendation to teach.

ps -- to others -- no, curse it all, I am not leaving my students with
   the idea that they should never use booleans or that they should
   write functions that return 500 integer ret vals.  Give me credit
   for some sense, please.  This is a training exercise to get you
   over the bad problem of writing bools when you shouldn't, nothing
   more.  My freind Kenji Okamoto, who has been teaching Python in
   Japan for 8+ years now says that this is a function of the English
   language, and Indo-European languages in general which have an 'is'
   verb.  People whose langages do not have them do not make too many
   booleans -- the trick is to get them to make any at all some times.
   But naive programmers in the Western language, he says, think always
   in terms of two valued logic 'is' or 'is not' properties.  This
   makes for bad programming practice.  It would be nice if he would
   discuss this more here, but his English is not great and he doesn't
   like to do so.  We must repect his wishes.

Laura Creighton





More information about the Python-list mailing list