PEP 285: Adding a bool type

[Chris Liechti]

Alex Martelli <aleax at aleax.it> wrote in
news:l_1q8.49099$S52.1668112 at news2.tin.it: 

> Aahz wrote:
> 
>> In article <KM_p8.41075$pT1.1129125 at news1.tin.it>,
>> Alex Martelli  <aleax at aleax.it> wrote:
>>>
>>>0 is (2.2 is still present, not yet past) the canonical way to spell
>>>untruth: it's what 'not', 'is', 'in', comparisons, and all standard
>>>library iswhatever's return -- including operator.truth, of course.
>> 
>> Just to throw in a datapoint, I generally use None to indicate
>> falsehood. 
> 
> ...and you can presumably continue to indulge in this quirk, if you so
> choose, after 285 passes.  'return 0' is obviously faster (a
> LOAD_CONST opcode, rather than a LOAD_GLOBAL for either 'return False'
> or explicit 'return None', where the latter always has to check
> globals() first and then proceed to the built-ins), but just as
> obviously the difference is so minute as not to matter -- a matter of
> 10% slowdown on my machine for 100,000 calls to a function whose body
> is just return None, versus one whose body is just return 0 (0.45 vs
> 0.41 secs for 100,000 calls including timing overhead, python -O,
> time.clock).  An _implicit_ return None (fall-off-the-end) would be
> just as fast as return 0, but I would consider it seriously obfuscated
> (while 'return None' strikes me as only moderately so -- just because
> of the difference wrt what all of the builtin and library
> equivalents). 

the above argument about speed seems to be stronger one against the change. 
it would mean that the python core must be adapted so that booleans are 
fast enough. there are enough (sometimes needless but still) questions 
about speed, don't put oil in the fire.

i agree that writing True instead of 1 clarifies code and it could be an 
advantage for RPC etc. but not in cost of speed and a hacky version:
- if str(True) prints '1' its still confusing for newbees at the prompt.
- the problems with 'var == True' and 'var == False' etc.
- backward problem with pickle and other serializing libs
- speed

i'm reading in the thread pros and cons, regarding the problems for such a 
small benefit of having True and False i vote for inluding it later in 
Python 3000, if ever.

chris

-- 
Chris <cliechti at gmx.net>