PEP 285: Adding a bool type

[Jacob Hallen]

1) Should this PEP be accepted at all.

No.

I come from a background where I have taught students hands-on programming
in the saltmines of my local university, taught engineers in the industry
how to program and where I have implemented actual programs for various uses,
from the humble MCU that controls a valve, to systems that manage the
collected literature of all academia in Sweden. I have taught using about
a dozen different programming languages and last I counted, I had written
programs in about 30 languages, including some assembler dialects.

My humble opinion is that new features in a language should make it easier
to accomplish what you set out to do - create a working program.

Python is a language that is weakly typed, essentially allowing a statement
like

x = f(y)

or

x = a + b

to assign a value of any type to x. This value may be an int, a float,
a string, a list or a dictionary (and an imaginary).

If we ignore the imaginary, which has a very specialized scope, we have 5
base types. These can interact in approximately 5! (120) different ways in a
statement. If we add one more base type we get 6! (720) different ways
that our types can interact.

For a student as well as an active implementor, it is necessary to learn
what the results of all (or at least most of) these interactions are.
Add one more base type and you have increased the complexity of the type
system by a large factor.

As a contrast, teaching how the current type system works is a matter of
a 15 minute lecture, that no student will misunderstand. The hard thing to
teach is how to interpret a "Type mismatch error" and why unexpected
automatic conversions happen. Automatic conversions are a pitfall even for
very seasoned programmers.

Closely related types also make things more difficult than highly ortogonal
ones. Booleans, like ints and floats are scalar, so relations between
these 3 will be more important than say, the relationship between an int and
a dictionary.

If we take the example of C++, one of the reasons it is really hard to teach
and to use is the very close relationship between references and pointers.
Of course it is very nice to be able to take a reference, cast it into a
pointer, subtract it from another pointer and get an int, or a long, or an
unsigned long, or whatever. (Yes, multiple length, closely related types
add a lot of complexity. (And I didn't even mention unsigned ;-))) 

You can learn to master complexity as you become proficient in a language and
you will select a subset of its features that you know and understand.
People who write C code and have never used a function pointer or an enum or
a const declaration are in vast majority, even though these are all great
tools in the right context. C is only moderately more complex than Python.


So, is a boolean always a waste of time?

No, I don't think so. In a statically typed language, they actually catch
some errors at compile time. Python is dynamically typed.

In a language for embedded applications, you can save execution time and
memory space by using a single bit for your boolean variable. Python
is good for many things, but it is not optimised for embedded applications.

It does add readability to some code to use the literals 'true' and 'false'.
Python contains ample constructs for the user to do this. You can even add
a module in the standard library called "bool", exporting "true" and "false".


Guido thinks this is a small change to the language. I strongly disagree.
My conclusion is that the addition of a boolean type to Python would
hit it where it hurts most. Python is a simple language, because it has
a very small and simple type system. Making it harder to learn by increasing
the complexity is going to drive Pythons core supporters - the biologists,
physicists, astronomers, sociologists and other scientists - to look for
other alternatives, that require less work to understand.

Jacob Hallén
AB Strakt

(Yes, I know that booleans are implemented in a cheat way according to the PEP,
 making them almost aliases for int 0 and int 1. I does not ease the burden
 of knowing the type interaction information.)
--