PEP 285: Adding a bool type

Cliff Wells logiplexsoftware at earthlink.net
Wed Apr 3 15:04:41 EST 2002


On Tue, 2 Apr 2002 21:21:27 -0500
John Roth wrote:

> 
> "Laura Creighton" <lac at strakt.com> wrote in message
> news:mailman.1017755045.4308.python-list at python.org...
> > Dear Guido:
> >
> > I would first like to thank you for giving us an opportunity to
> respond.
> > I have spent most of the weekend thinking and writing a reply to this,
> > and I think that this has made me a better teacher.  For this I am
> > grateful.  I realise that this is rather long, but I have condensed
> > it substantially from my efforts earlier this weekend.   Thank you
> > for taking the time to read this.
> >
> > Laura Creighton
> >
> > -----------------------------
> >
> I'm not going to quote this, as it's already too long. I read up to
> the diatribe on the Swedish leap year, and I went AAAARRRRGGGH!
> 
> I really don't care if you want the silly function to return
> a Boolean, the number of leap days in the year, or the name
> of the idiot parliamentarian who decided to fix the calendar
> so that 1712 was different from the rest of Europe.
> 
> HOWEVER, if you want true or false as the return
> value, the name should be something like 'isLeapYear()'.
> If you want the number of leap days in the year, then
> it should be named something like 'numberOfLeapDays().'

> Sorry to make this sound like a flame, but I try to
> practice XP. The first time I ever come across a
> function named "isSomething" that returns a conceptual
> integer, it's going to get refactored, right then and
> there to a name that actually expresses what it does.

Laura was using the example given by Guido, since she was responding to
Guido's statements. 
I totally agree that a function name that implies a boolean should return a
boolean.  Guido was stating otherwise, that a boolean could also be used as
an int, which Laura felt (and apparently you and I agree) is wrong.  If you
had read the entire post you would have seen that that was (partially) her
point:

[GvR]
>     4) Should we strive to eliminate non-Boolean operations on bools
>        in the future, through suitable warnings, so that e.g. True+1
>        would eventually (e.g. in Python 3000 be illegal).  Personally,
>        I think we shouldn't; 28+isleap(y) seems totally reasonable to
>        me.

[Laura]
> This is not an argument for allowing non-Boolean operations on bools();
> this is an argument for not writing functions that return Booleans.  Make
> them return numbers instead, so that you can use them as you did.  Last
> month we discussed why in 1712 February had 30 days in Sweden.  (See:

So what you are saying fits perfectly with what Laura asserted.  If you
have a function numberOfLeapDays() why on earth would you need
isLeapYear()?  The solution is simple: don't return a boolean when another
type can not only express true/false but also convey other information as
well.

I didn't necessarily agree with all of Laura's assertions regarding the
difficulty of understanding how booleans would fit into Python, but she
raised several compelling and thoughtful arguments.  I totally agree that
bools as return values of functions are less than useful.  Booleans have
the lowest information density of any type and thus would tend to increase
code verbosity if their use were to be encouraged.

Frankly Guido's dismissal of Laura's arguments as FUD was not only a bit
rude, but IMHO a bit short-sighted as well (given the fact that someday,
there may be a desire for a real boolean type).  Maybe Tim Peters has
borrowed his time-machine and not returned it ;)


-- 
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308  (800) 735-0555 x308





More information about the Python-list mailing list