Mailman 3 March 2002 - Python-Dev

For review: PEP 285: Adding a bool type
by Guido van Rossum March 11, 2002

March 11, 2002

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

19 75

test_largefile.py failing on Linux
by Guido van Rossum March 11, 2002

March 11, 2002

In the most recent checkout on Linux, test_largefile.py fails. The output is: [guido@pcp742651pcs linux]$ ./python ../Lib/test/test_largefile.py create large file via seek (may be sparse file) ... check file size with os.fstat 2500000001L =?= 2500000001L ... yes check file size with os.stat 2500000001L =?= 2500000001L ... yes play around with seek() and read() with the built largefile 0L =?= 0 ... yes 'z' =?= 'z' ... yes 1L =?= 1 ... yes 0L =?= 0 ... yes 0L =?= 0 ... yes 42L =?= 42 ... yes 42L =?= 42 ... yes 84L =?= 84 ... yes 84L =?= 84 ... yes 2500000001L =?= 2500000001L ... yes 2499999991L =?= 2499999991L ... yes 0L =?= 0 ... yes 2500000000L =?= 2500000000L ... yes 'a' =?= 'a' ... yes 'z' =?= 'z' ... yes 1L =?= 1 ... yes play around with os.lseek() with the built largefile 0L =?= 0 ... yes 42L =?= 42 ... yes 84L =?= 84 ... yes 84L =?= 84 ... yes 2500000001L =?= 2500000001L ... yes 2499999991L =?= 2499999991L ... yes 0L =?= 0 ... yes 2500000000L =?= 2500000000L ... yes 'a' =?= 'a' ... yes try truncate 2500000001L =?= 2500000001L ... yes 2499999990L =?= 2499999990L ... yes 2499999990L =?= 2499999990L ... yes 0L =?= 2499999989L ... no Traceback (most recent call last): File "../Lib/test/test_largefile.py", line 149, in ? expect(f.tell(), newsize) File "../Lib/test/test_largefile.py", line 59, in expect raise test_support.TestFailed, 'got %r, but expected %r' %\ test_support.TestFailed: got 0L, but expected 2499999989L [guido@pcp742651pcs linux]$ --Guido van Rossum (home page: http://www.python.org/~guido/)

3 2

Re: [Python-Dev] For review: PEP 285: Adding a bool type
by Hans Nowak March 11, 2002

March 11, 2002

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/

10 11

Bug changes emails: SF problem?
by Just van Rossum March 10, 2002

March 10, 2002

I don't always seem to get an email when a bug that I submitted was modified. Has anyone else noticed this? Just

3 4

bools aren't ints in Fortran
by Paul F Dubois March 10, 2002

March 10, 2002

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

2 1

Jython and bool
by Samuele Pedroni March 10, 2002

March 10, 2002

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.

1 0

Psyco release 0.4.0
by Armin Rigo March 10, 2002

March 10, 2002

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.

4 5

Re: [Python-Dev] For review: PEP 285: Adding a bool type
by Samuele Pedroni March 10, 2002

March 10, 2002

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

3 6

Two developer candidates
by Skip Montanaro March 10, 2002

March 10, 2002

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

7 15

Weekly Python Bug/Patch Summary
by Skip Montanaro March 10, 2002

March 10, 2002

1 0