PEP 285: Adding a bool type

[Ken Seehof]

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

In python the number of numeric interactions is essentially 3!, not 6!.
Most of these interactions are trivial and predictable, and are not
increased
by bool.  My brain hurts trying to figure out how to enumerate the 6! that
you suggest :-)  Perhaps in other languages your argument has merit.

One thing that I agree with is that one would not be likely to add a bool to
a complex number.  :-)

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

Properly used bools will tend not to interact with other numeric types in
practice.  Anyway, a TypeError won't occur.

> 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 ;-)))

Sure, but we are talking about python here.  I agree that C++ suffers
greatly from the proliferation of numeric types.

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

The net effect of PEP 285 is very similar to that suggestion.  Except that
the PEP has several advantages, such as having a __repr__ that returns
"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.)

Yes it does.  There isn't any new type interaction information associated
with adding bool (except the information that there isn't any new type
interaction information associated with adding bool :-)

- Ken Seehof