PEP 285: Adding a bool type

[Alex Martelli]

Ype Kingma wrote:
        ...
>> > The problem is that a lot of code has been written assuming 1/0
>> > behaviour of boolean values.
>> 
>> The "problem" is that behavior is VERY useful.  So, taking it out would
        ...
> I wasn't talking about removing this behaviour, although I don't like it.

When I call a language feature "VERY useful" it sort of implies I like it
(well, I AM an engineer -- "useful" and "beautiful" are almost synonyms
for our ilk:-) and therefore I object to it being called a _problem_:-).  I
put "problem" in quotes for the same purpose, to indicate a "so to speak".


> Thank you for pointing this out. I only read the contents of both parts
> (the language ref and the standard library ref) and based my post on that.
> I should have read the manual completely.

I agree that you should have.


>> This is the Python LANGUAGE we know and love -- the LANGUAGE
>> Reference says so, and us Language Lawyers know that.  You want to
>> change Python, that's one thing.  But don't tell us that this part of the
>> Language Reference "is not part of the python language".
> 
> I do not want to change that part of the language. I tried to
> say that the backward compatible 1/0 behaviour and
> the Something/Nothing behaviour can be implemented in the special methods
> of the standard types, even when a non int-a-new-hat bool would be added
> to the language.

Even if having to modify the __getitem__, __setitem__, __delitem__ (at
the least) of a zillion user-defined types out there was feasible (and it's
not), I think this would not fully exhaust, as I indicated.

> but they are already explicitly available. (How often do you
> actually need slices? I'd expect you to use bool more often
> than that if you could.)

I use slices in every sequence-like type I code -- a slice object
is what gets passed to my __getitem__ (etc) methods when
client code uses myobject[3:] or whatever (special methods
__getslice__ etc are deprecated for new objects, although for
backwards compatibility they're still used if present, and quite
unfortunately list &c still use them).  My __getitem__ &c need
to know whether they're called with an index that has .start
and .stop attributes (I feature-test for those, obviously, NOT
typetest for slice!) or with an index that is a number.  I feel
absolutely no need to know whether an argument passed to
my object's method comes from -- and on the other side of
things, to know whether my object is being tested for truth,
why, I already have the (unfortunately named) __nonzero__.

When this PEP passes and 2.3 becomes the only Python
release that my code must support I may have to switch to
"return True" vs "return 1" -- we're quite keen on the concept
of *TEAM* programming, against "code ownership", and part
of that is that everybody follows strict coding-style standards.
If we agree on coding-style standards mandating this, then I
will follow them -- not happily, but I will.  And that's the extent
of "use" (not "usefulness") I expect from booleans.


> Indexing a dict with both int and bool keys might involve some confusion
> when True is not 1 anymore. This case should be rare, however.

Why should it be rare?  All hashables are used uniformly as keys
into dictionaries.

> For standard types, ie. normal dictionaries there is no problem since
> one can simply add the int() method call in the implementation of
> __getitem__ of the standard dictionary for backwards compatibility.

You propose a substantial slow-down of standard dictionaries "for
backwards compatibility" against an incompatibility that need never
be introduced in the first place -- you can't "simply add the int()
method call", you first have to typetest against boolean on EVERY
dictionary access to know if the "int()" kludge is needed at all (you
can't just call int() on EVERY key without breaking a megazillion
lines of code -- i hope you realize that? -- and if you could that
would be a slow-down too).  I don't think you realize at all how
CRUCIAL dictionary look-up performance is to Python.  The number
of dictionary accesses is huge in every real Python program.  If there
is one thing that MUST be always optimized, that's the one.

The incompatibility is needless: apart from un-engineeringly yearnings
for "purity" (which, in Python, is trumped by pragmatics) there's no
reason for hash(True) to differ from 1, and True==1 is similarly not
a problem at all.  Easiest would be not to distinguish booleans from
ints at all, second easiest, as the PEP proposes, to make booleans
a subclas of ints, but even without the latter pragmatic fix a sensible
strategy would still be feasible.  Slowing down all dictionary access
is NOT a sensible strategy, nor acceptable at all.

Slowing down all list accesses as you want to do is not quite as
horrible, but still a pretty bad move.  What Python most needs right
now is a bit more attention to performance issues, NOT slow-downs
in its core to satisfy some people's desires for "purity".


> User code trying to implement a dictionary will need a similar
> fix as I pointed out above. I can only hope there is no more breakage in
> user code.

"only hope" is not acceptable in this context.  Fortunately, we can
do better than that (and I'm confident that the unacceptability of
slowing down dictionaries and lists is quite obvious to decision
makers in this case, so I don't fear it will happen).


Alex