PEP 285: Adding a bool type (partially OT)

[Alex Martelli]

Ype Kingma wrote:
        ...
> The language spec does not specify the type of the index or key
> argument to __getitem__.

It does for sequences (int and slice only) and for dictionaries (any
hashable) but not for other mappings (each mapping define its
own rules: something like "only a string is accepted" is quite
common in various mappings implemented in the standard
library, for example).


>>     - testing membership with aset.has_key(item),
>> or:
>>     - indicating membership with aset[item] = 1, then
>>     - testing membership with aset.get(item, 0)
>> 
>> Why would you think this is "rare"?  It's common currency.  How many tens
>> of thousands of lines of python have you written, reviewed, or
>> maintained, that you presume to teach me what is common and what is rare
>> in python "as she is spoken", pray?
> 
> In how many of these cases would the 'item' key actually be confused
> when it could be either a bool or an int? So far you failed to convince me
> that this is not a rare case.

What does it matter what type the item is?  has_key must now return
a Boolean, while the get idiom that always was equivalent to it must
keep returning int.  Any existing code that has tests coded both ways,
for ANY type of item, will return "mixed" Booleans and int's.  Modern
equivalent idiom "item in aset" also returns Boolean, but THAT is quite
likely rare since it only became possible in Python 2.2.  Still, where 2.2
was accepted as the used language version, whenever the get idiom
was used I refactored it into the 'in' operator on code I was revising
anyway (but not on parts of code I wasn't revising) -- clearer, more
concise, AND faster... irresistible (the "one obvious way to do it", once
it became acceptable).

> Even though I don't see the relevance of the second question
> the answer is: a few, and I'm not teaching here, I'm explaining
> my opinion.

Based on WHAT experience of Python, that's what I'm asking --
maintenance responsibility for how many tens of thousands of lines,
etc.  How can you have a sound opinion on what is rare or frequent if
not on the basis of some reasonably representative sample?


>> > That should only happen when True and 1 are used interchangeably,
>> > which might happen by programmer mistake or by using
>> > old (1/0) and new (True/False) style code together.
>> 
>> Old-style only will do perfectly well, since lots of extremely common
>> idioms therein (a<b, d.has_key(k), x in y, and so on) change return
>> values silently.  Neither any mistake nor any 'together' is needed,
>> unless you're somehow trying to imply that anybody coding some kind
>> of "advanced" (?!) construct such as "a<b" was using "new style code"
>> unwittingly years ago...
> 
> By new style I meant explicit use of True/False. 

So do I: and there is absolutely no "explicit use of True/False" in any
of the several expressions I enumerted, nor the many more whose
return type change silently from int to Boolean.  "True and 1 are used
interchangeably" in any existing function that can return any of these
expressions OR an explicit 0 or 1, as in:

def isValueAtIndex(alist, anindex, avalue):
    if -len(alist)<=anindex<len(alist):
        return alist[ainindex] == avalue
    else:
        return 0

or equivalently and more Pythonically:

def isValueAtIndex(alist, anindex, avalue):
    try: return alist[ainindex] == avalue
    except IndexError: return 0

There is absolutely no programmer mistake here, nor any use of old
style and new style code together.  Yet such existing code may very
well return int or Boolean interchangeably _because the return type
of very common operations has changed silently in 2.3_ ... !!!

> As for "advanced (?!): I don't have a time machine.

So you'll have to admit that claiming "interchangeable return of int
or Boolean" can only be caused by mistakes or "mixing old and
new style" was a wildly unfounded assertion, yes?


>> > In the pure case an int() call would not be needed at all:
>> 
>> But to check whether it's needed or not, a type-check would be
>> needed, and that IS a substantial slow-down.  You don't seem to
> 
> If it's not needed at all, there is also no need for the check.

How do you *KNOW* whether to check or not, without a check?


> I am not talking about an actual implementation.
> I'm talking about a specification, while trying to keep an eye on
> implementABILITY.
> Since you didn't say it cannot be done, I'm actually encouraged.

It IS quite possible to implement a language where the semantics
of, say, + and - operators, are switched in any source line which has a
prime number of characters.  It IS totally absurd, but clearly feasible.

Why such technical feasibility would encourage anybody to consider
such absurdities is beyond me, but please feel free to go ahead and
implement such a beauty.  It will still be less absurd and abstruse
than your cherished "implementable" specification, anyway.


Alex