PEP 285: Adding a bool type

Steve Holden sholden at holdenweb.com
Fri Apr 5 16:09:41 EST 2002


"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().'
>
Just so John know he isn't the only person going AARRGGHH, I read this went
AARRGGHH myself. It should not be named "something like
'numberOfLeapDays()'". It should be named LeapDays(), or possibly
LeapDayCount() if you also have a function that returns the actual dates
which ARE the leap days. Or, I suppose, you could call it
"theNumberOfLeapDaysInTheSwedishYear()" ;-)

> > 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.
>
People who live in glass houses ...

> 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.
>
It seems plain (now I've read so much of the discussion) that if book isn't
going to behave as a full-blown Boolean object it would be better to leave
well enough alone.

> 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.
>
I too thought Laura made a thoughtful contribution to the discussion, that
deserved to be considered more respectfully.

> 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 ;)
>
However it happened, it left me feeling a little embarrassed that I had
originally defended Guido's inegrity and suggested that despite his
authorship the PEP's acceptance was not a foregone conclusion. I hope I
wasn't wrong, but that's not how it looks right now. Oh well.

regards
 Steve







More information about the Python-list mailing list