I'll let this short and sweet PEP speak for itself.
http://python.sourceforge.net/peps/pep-0285.html
PEP: 285
Title: Adding a bool type
Version: $Revision: 1.1 $
Last-Modified: $Date: 2002/03/08 15:38:37 $
Author: guido(a)python.org (Guido van Rossum)
Status: Draft
Type: Standards Track
Created: 8-Mar-2002
Python-Version: 2.3
Post-History: 8-Mar-2002 (python-dev)
Abstract
This PEP proposes the introduction of a new built-in type, bool,
with two constants, False and True. The bool type would be a
straightforward subtype (in C) of the int type, and the values
False and True would behave like 0 and 1 in most respects (e.g.
False==0 and True==1 would be true) except repr() and str(). All
built-in operations that conceptually return a Boolean result will
be changed to return False or True instead of 0 or 1; for example,
comparisons and the "not" operator.
Rationale
Most languages eventually grow a Boolean type; even C99 has one.
It's useful to be able to tell from a function result that the
outcome has Boolean semantics.
Specification
The following Python code specifies most of the properties of the
new type:
class bool(int):
def __new__(cls, val=0, _create=0):
if _create:
# This is nor part of the spec,
# just a hack to bootstrap False and True
return int.__new__(cls, not not val)
elif val:
return True
else:
return False
def __repr__(self):
if self:
return "True"
else:
return "False"
__str__ = __repr__
def __and__(self, other):
if isinstance(other, bool):
return bool(int(self) & int(other))
else:
return NotImplemented
__rand__ = __and__
def __or__(self, other):
if isinstance(other, bool):
return bool(int(self) | int(other))
else:
return NotImplemented
__ror__ = __or__
def __xor__(self, other):
if isinstance(other, bool):
return bool(int(self) ^ int(other))
else:
return NotImplemented
__rxor__ = __xor__
False = bool(0, _create=1)
True = bool(1, _create=1)
Issues
Because the repr() or str() of a bool value is different from an
int value, some code (e.g. doctest-based unit tests) may fail.
How much of a backwards compatibility problem this will be, I
don't know. If we find this is a real problem, we could add a
command-line option to make False and True aliases for 0 and 1 and
bool an alias for int.
Copyright
This document has been placed in the public domain.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
fill-column: 70
End:
--Guido van Rossum (home page: http://www.python.org/~guido/)
This may be a minor issue, but this proposal will break code like
days_feb = 28 + isleapyear(year)
assuming that booleans cannot be added to ints. :-)
isleapyear can be defined like this:
return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)
like it is in calendar.py. In the new situation it would return a boolean. Now
I realize that code using isleapyear this way is easily fixed (especially if
we would be able say int(True) or int(False) to get the numerical value
again), but my point is, it takes away a (IMHO) nice side effect of using
these values as numbers.
I'm not sure if there's a lot of code out there that actually uses these
numerical values. I occasionally use it, though... I guess that's what I get
for bad programming practices. :-)
--Hans Nowak (vaporeon(a)wanadoo.nl)
http://www.awaretek.com/nowak/
Paul Prescod wrote to Tim:
> Here are other languages that (based on some admittedly cursory
research) treat booleans > as entirely distinct from
> integers:
> * Scheme
> * SML
> * JavaScript
> * Visual Basic
> * Eiffel
> * Smalltalk
> I'd be curious to hear a list of high level, GC'd languages in the
other camp. Methinks > your Fortran/C bias shows. ;) And it isn't
pretty."
Add to your list, "Fortran", which has type "logical". This makes the
bias comment self-canceling, but reinforces the argument against bool
being a special case of int.
I think bools as ints started as a "close to the hardware" motivation,
and doesn't have much of a place in modern programming. All the
arguments for it seem to be claims for ease of expression but against it
is ease of correctness. I think the latter is necessary and the former a
nicety.
BTW, the Fortran standard does not specify a representation for logical,
and there was even a period where mixing libraries compiled with
different compilers on the the Crays could get errors because the
representations differed. One compiler had chosen to use a hardware
feature that made it quick to test a sign bit. This points out another
fallacy with making bool a subclass of int -- it binds the
implementation too much to one view.
True + True is neither True nor False. Hmmmmmm....
Maybe this is insightful, namely how Jython
now deals with Java methods with boolean in
their signature and overloading, and the possible
scenarios in case the PEP is approved.
Let's consider the following Java class:
public class Ex {
public void mint(int v) {}
public void mib(boolean b) {}
public void mib(int v) {}
public mbool(boolean b) {}
boolean mtrue() { return true; }
boolean mfalse() { return false; }
void pass(Object o) {}
void passBool(Boolean bo) {}
}
let ex=Ex() be an instance of Ex.
*** NOW
ex.mint(0) and ex.mint(1) do the obvious thing
ex.mib(0),ex.mib(1) call ex.mib(int v)
ex.mbool(0) and ex.mbool(1) invoke ex.mbool with false and true
ex.mbool(non-integer-non-java.lang.Boolean) fails
ex.mtrue() returns 1
ex.mfalse() return 0
which means that ex.mib(ex.mtrue()) calls ex.mib(int v).
[ to call ex.mib(boolean b) one should use ex.mib(java.lang.Boolean(value)) ]
ex.pass(0) and ex.pass(1) call ex.pass with java.lang.Integer(0) and
java.lang.Integer(1)
ex.passBool(0) and ex.passBool(1) call ex.pass with
java.lang.Boolean.FALSE and java.lang.Boolean.TRUE
*** with True and False, bool is subclass of int
A) treat True as 1, False as 0 and leave everything as above (no pain,no gain)
that means for dispatching java methods int and bool are the same,
possibliy ex.mtrue() returns True and ex.mfalse() returns False
B)
ex.pass(0) and ex.pass(1) call ex.pass with
java.lang.Integer(0) and java.lang.Integer(1).
ex.passBool(0) and ex.passBool(1) call ex.pass with
java.lang.Boolean.FALSE and java.lang.Boolean.TRUE
ex.pass(False) and ex.pass(True) call ex.pass with
java.lang.Boolean.FALSE and java.lang.Boolean.TRUE
(plus warning in the transition phase), same for ex.passBool
ex.mtrue()/ex.mfalse() return True/False
ex.mbool(non-integer-non-bool-non-java.lang.Boolean) fails
ex.mbool(0) and ex.mbool(1) invoke ex.mbool with false and true
ex.mbool(False) and ex.mbool(True) invoke ex.mbool with false and true
ex.mib(0),ex.mib(1) call ex.mib(int v)
ex.mib(False) and ex.mib(True) call ex.mib(boolean b)
issuing a warning during a transition phase [involved to issue!]
[ex.mib with a java.lang.Boolean still calls ex.mib(boolean b) so no problem
there]
ex.mint(0) and ex.mint(1) do the obvious thing
ex.mint(False) and ex.mint(True)
either fail [easy to implement] or call ex.mint with 0/1 [involved!] (?)
*** with True and False, bool disujunct from int
ex.pass(0) and ex.pass(1) call ex.pass with java.lang.Integer(0) and
java.lang.Integer(1)
ex.passBool(0) and ex.passBool(1) maybe should *fail* after long transition ?
ex.pass(False) and ex.pass(True) call ex.pass with
java.lang.Boolean.FALSE and java.lang.Boolean.True
(plus warning in the transition phase), same for ex.passBool
ex.mtrue()/ex.mfalse() return True/False
ex.mbool(non-bool-non-java.lang.Boolean) and
ex.mbool(0) and ex.mbool(1) should *fail* after long transition ?
ex.mbool(False) and ex.mbool(True) invoke ex.mbool with false and true
ex.mib(0),ex.mib(1) call ex.mib(int v)
ex.mib(False) and ex.mib(True) call ex.mib(boolean b)
issuing a warning during a transition phase [involved to issue!]
[ex.mib with a java.lang.Boolean still calls ex.mib(boolean b) so no problem
there]
ex.mint(0) and ex.mint(1) do the obvious thing
ex.mint(False) and ex.mint(True) should fail after transition and
maybe call ex.mint with 0/1 with warning during transition phase [involved!]
(?)
"maybe should *fail* after long transition ?" questions:
Very likely not, user will be very unhappy to
have to change all their
jframe.setVisible(1)
or equivalent jframe.visible = 1
So for Jython bool solves a very minor wart
with a more or less affordable transition cost and
increasing amounts of purity only make us
guilty not to able to do something with them,
for *very* practical reasons <wink>.
regards.
Hello everybody,
The first beta version of Psyco is released, with Windows and Linux
binaries, for Python 2.1 and 2.2. Any feedback welcome!
http://sourceforge.net/projects/psyco/
Thanks,
Armin.
>
> > Damn, you're right. I'll patch doctest to special-case the snot out of
> > those specific strings <wink>. In the meantime,
> >
> > def ibool(e):
> > return e and 1 or 0
> > # or "return operator.truth(e)"
> >
> > will work across all Pythons forever, or back to 1.4 if you use
> > operator.truth to avoid offending yourself <wink>.
Btw given that probably operator.truth() will
become a synonym of bool() the "# or" comment
does not apply.
Tim, should we start to be worried about the problems you have
to get those things right or are you just in very-low-concetration mode?
regards, Samuele Pedroni.
Folks,
I've received just two requests from people to become developers:
Jeff Bauer (jeff(a)rubic.com)
Bernard Yue (bernie(a)3captus.com)
Jeff I know personally, as the Developer's Day chair and the WinCE port
maintainer. I don't know Bernie though I recognized his name. The posts I
saw from him on google were all answers to questions other people had. Sort
of looked like a mini-python-help archive. Bernie is the chief architect at
3captus in Hong Kong. They produce a product in Python that takes data
feeds from other sources and creates XML-RPC or SOAP servers that can be
used to generate subscription-based services.
I don't have a problem with either Jeff or Bernie being granted developer
privileges. Feel free to add your two cents.
Skip
