PEP 285: Adding a bool type

[Ype Kingma]

Laura,

<snip>

> 
>         4) Should we strive to eliminate non-Boolean operations on bools
>            in the future, through suitable warnings, so that e.g. True+1
>            would eventually (e.g. in Python 3000 be illegal).  Personally,
>            I think we shouldn't; 28+isleap(y) seems totally reasonable to
>            me.
> 
> This is not an argument for allowing non-Boolean operations on bools();
> this is an argument for not writing functions that return Booleans.  Make
> them return numbers instead, so that you can use them as you did.  

I couldn't agree more.
The problem is that a lot of code has been written assuming 1/0 behaviour
of boolean values.

If there were a real boolean type in Python this backward
compatible behaviour can be implemented in the __add__, __radd__
and other special methods of the numeric classes (see the language reference on special
method names: http://www.python.org/doc/current/ref/specialnames.html).
They would work by using the value 1 or 0 when encountering a boolean value.

<snip>


>     Rationale
> 
>         Most languages eventually grow a Boolean type; even C99 (the new
>         and improved C standard, not yet widely adopted) has one.
> 
>         Many programmers apparently feel the need for a Boolean type; most
>         Python documentation contains a bit of an apology for the absence
>         of a Boolean type.
> 
> So fix the docs, don't change the code! <wink>.  I think the fact that
> in python control flow structures distinguish between Something and
> Nothing is one of the beauties and glories of the language, and you
> should delete any documentation that says otherwise.

The documentation for this is in the library reference, not in the language
reference.

> 
>         I've seen lots of modules that defined
>         constants "False=0" and "True=1" (or similar) at the top and used
>         those.  The problem with this is that everybody does it
>         differently.  For example, should you use "FALSE", "false",
>         "False", "F" or even "f"?  And should false be the value zero or
>         None, or perhaps a truth value of a different type that will print
>         as "true" or "false"?  Adding a standard bool type to the language
>         resolves those issues.
> 
> So would adding True and False to the __builtins__, and probably
> operator.truth as well, and then modifying PEP 8 saying to use the
> things if you actually have a need for True and False.  Then you could
> also get a much needed word in edgewise discouraging
> 
> if bool(x) == True:
> 
> or actually using True and False much, because there is usually a better
> more pythonic way to do what people used to other languages are accustomed
> to doing with booleans.  This is precisely what some people have said
> here: 'When I started using Python, I made True and False, but once I
> stopped trying to program in some other language using python, I
> stopped needing these things'.  (see the recent post by Don Garrett
> <garrett at bgb-consulting.com> in this thread for an example.)
> 
> This is what I have observed as well.  And I fear if you add these new
> types to the langauge people will never take this step.  The existence
> of the types in the language will discourage them from thinking that using
> True and False all the time is not pythonic.  It is nice that people are
> puzzled, wondering how all those python programmers live without a
> boolean type.  Eventually they puzzle it out.  This is not a bug, but
> a feature <wink>.

Thanks for putting this so explicitly.

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.

Whenever you derive a boolean from, ie. call __len__() or __nonzero() on, objects
of the standard types they act as Something/Nothing objects which allows one
to think like:

if something_there:
    ...
else: # nothing_there
    ...

A real boolean is required to control the conditional branch.
Since slices are also explicitly available, I'd like a real boolean
to be available. It fits the language.

> 
>         Here are some arguments derived from teaching Python.  When
>         showing people comparison operators etc. in the interactive shell,
> 
>         I think this is a bit ugly:
>             >>> a = 13
>             >>> b = 12
>             >>> a > b
> 
>             1
> 
>         If this was:
>             >>> a > b
> 
>             True
> 
>         it would require one millisecond less thinking each time a 0 or 1
>         was printed.
> 
> This is the basis of our disagreement.  I think that it is very, very
> important that much more than a millisecond be spent on this.  This is a
> fundamental python concept, which I want to teach.  This is precisely
> where you learn that python distinguishes between Something and Nothing,
> and if you have a problem seeing why this implies  a > b printing as 1,
> then you probably have a problem with the whole concept.  And making it
> return True is precisely what I never, ever, ever want a python learner
> to see.
> 

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.

> 
> I think that a really strict boolean might be nice to have.  And if you
> ever write one, you will curse the day you let this hack be named bool.
> Replacing this int-with-a-hat with real bools will break so much
> code.
> 

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.


> I don't want to have to teach the pythonic meaning of True and False to
> people who already believe they know what True and False is.  This is
> going to be hell.  It is about as hard a thing as there is in teaching,
> getting around people's previous conceptions.

Starting with only the Something/Nothing background it would indeed be
problematic to teach about True/False. However an implied derivation of
of True/False from Something/Nothing is no problem, eg. 'if 1:' is easy to
teach.

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.

<snip>

Regards,
Ype

-- 
email at xs4all.nl