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
reduce productivity (by a little) as well as making the language harder to
teach (by a little or by a lot -- I used to think "by a little", Laura's 
post is making me thing it may well be "by a lot").


> This Something/Nothing feature is indeed very useful.
> However, it is not part of the python language, it is part of the way in
> which the standard types are implemented.

The Language Reference manual of the Python language disagrees
with you.  E.g. at http://www.python.org/dev/doc/devel/ref/Booleans.html :

"""
In the context of Boolean operations, and also when expressions are
used by control flow statements, the following values are interpreted
as false: None, numeric zero of all types, empty sequences
(strings, tuples and lists), and empty mappings (dictionaries).  All
other values are interpreted as true.
"""

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

> if something_there:
>     ...
> else: # nothing_there
>     ...
> 
> A real boolean is required to control the conditional branch.

If you say so.  In this case, since we DO "control the conditional branch"
in the current version of Python, then we HAVE "A real boolean" whatever
that may be (as defined by the language reference, see above).  Every
value in Python is "A real boolean", since any can "control the conditional
branch".


> As I said, it's not in the language, it's in the standard types.
> The millisecond is spent on the implicit derivation of a boolean
> in the readers' head. The  interpreter does the same thing, although
> faster.

There's no delay at all in my mind as I parse "if zebras:" -- there
WOULD be if that had to carry excess verbiage (to get a "real",
"pristine" boolean type -- which fortunately the PEP does not
propose, thanks be).  There's no delay in the minds of students
for which the Python something/nothing concept has 'clicked'.  I
read Laura's point as it being crucial to make that concept click,
and the existence of True/False being a substantial obstacle to
making it click.


> After having my head set straight on this by Martin v. Loewis
> (see the thread 'but not as int subtype') I concluded in favour
> of PEP 285, with the remark that what can in the future
> not be implemented using the special methods of bool and current
> standard types should be deprecated at the same time the PEP
> gets into force. The only example of such code I know of
> is user implementations of __getitem__, ie. objects
> indexable with square brackets, that are actually indexed with bool
> arguments. When all such user code has been fixed, there is nothing in the
> way of a real boolean type that is not an int-in-new-hat.

Do you propose to make your "real boolean type" non-hashable,
so that it can't be used to index into a dictionary?  Can you please
clarify the reason for *THAT*?

If you do NOT want to forbid usage of your newfangled booleans
as keys into dictionaries, then you're at least using imprecise language
in talking about "objects indexable with square brackets", since
dicts are indeed thus indexable (and more generally so are all
mappings).  Besides, would adict[True] be the very same dict entry
as adict[1], or not?  If they aren't to be the same entry, then how do
you propose to transition smoothly from a present in which they are
to a future in which they are not?  If they are, you need hash(True)
to be 1 and True==1 to hold (or else dicts would be seriously slowed
down -- a pythonic nono! -- and user-coded mappings would have
serious problems too), so SOME level of confusability must be kept.

I think the best levels of confusability (interchangeability, polymorphism, 
name it as you will) between concepts are "all" and "none", in general.  If
"all", the concepts are practically coincident even though there may be
some _conceptual_ separation that has no reflection in practice; if "none",
the concepts are utterly separate in practice even though there may be
some _conceptual_ common ground.  Either of these is easy to teach.
Middle-ground is harder to teach, though there may be very good (real,
practical -- or even philosophical) reasons to pay this price in some cases.

I don't think "none" is feasible here, and I much prefer the current status 
quo of "all" anyway.  The PEP has a lot of confusability (thanks to 
inheritance and True==1, perhaps even to str(True) being '1' depending on 
how that's decided); your proposal has very little (but, I think, not 
"none" -- see above).  So there's a conceptual price to pay, as well
as a pragmatic one (low for the PEP, high indeed for your proposal).  And
I _still_ don't see that the claimed benefits would actually amount to a
substatial hill of beans.  I have nothing against beans, particularly in my
soup, but they seem to come too dear here -- for a price I might perhaps
be willing to pay for good steak, if that.  High price, tiny benefit, my 
personal mental scales slant more and more towards a 'nay'.


> In fact this could be seen as a good example of the usefulness of
> object orientation: it allows separation of concerns to the extent
> that the standard types are documented separately from the language.

But that's NOT what the Python Language Reference chooses to do
for "Booleans" -- it documents them right smack in the middle of
the Language Reference itself.  So?


Alex