PEP 285: Adding a bool type

[John Roth]

"Cliff Wells" <logiplexsoftware at earthlink.net> wrote in message
news:mailman.1017865089.20676.python-list at python.org...
> 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.

Agreed.

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

You need both because the fact that the number of leap days
is either 0 or 1 is not exactly obvious unless you know the algorithm.
Using a number where you need to use a boolean is just as bad
as using a boolean where you need to use a number.

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

Disagree. Clarity is more important than code density.

> 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 ;)

I agree, and he's already commented on that elsewhere. I would
not have classified it as FUD - I disagree with Laura's analysis, but
what she said wasn't FUD in any reasonable definition of the term,
it was simply wrong.

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