Booleans (was Re: My .02 on PEP308 + an extra question)

Stephen Horne intentionally at blank.co.uk
Mon Mar 3 04:22:13 EST 2003


On Sun, 2 Mar 2003 14:31:04 GMT, Andrew Koenig <ark at research.att.com>
wrote:

>In particular, despite the disadvantages of allowing implicit
>conversions to and from bool, the type has two substantial advantages:
>
>        1) You don't have to worry about combining libraries that
>           use different conventions for representing boolean types.
>        2) You can overload based on it.
>
>These two advantages -- particularly the first -- were deemed to be
>sufficient by themselves to justify introducing a new type.

The trouble is these advantages rarely apply in reality, at least in
C++. That is...

    1)  You do have to worry about combining libraries that use
        different conventions for boolean types because so many
        libraries are written without using the bool type - the
        bool type is just one convention among many.

        There is no real compulsion to use bool, so this really
        doesn't seem to be getting better over time.

    2)  You can't safely overload based on it because so many
        'boolean' results are actually integers. Miss an explicit
        cast and you get the wrong function and a very had to find
        error (because it still 'looks' like it should call the
        right function to a human reader who knows the boolean
        semantics of the result). Overloading a function name to
        accept either a bool or an int parameter is begging for bugs,
        unless the functions are semantically equivalent in which case
        the overloading is pointless.

Of course both of these problems go away in certain contexts (when you
are not swamped in old code, C-style code, Win32 API calls etc) but as
I never seem to experience these contexts, well, at least my prejudice
has some justification ;-)

Whether these arguments apply in Python is yet to be determined -
experience will tell. I have to admit, I hadn't thought about possible
advantages with 'repr' and 'eval' (as Jeremy Fincher described) - in
C++ you CAN get similar advantages according to the overloading
principle, but it rarely happens. In Borland C++ 5.02 (still my
everyday compiler, sadly) the following code...

  #include <iostream>

  int main (int argc, char *argv [])
  {
    cout << true << endl;
    return 1;
  }

... actually outputs '1' rather than 'true', for instance. I really
don't know if the C++ standard says this is wrong, but if Python does
better this is definitely an advantage. Even if a cast is needed, it
still avoids the need for an "x then 'True' else 'False'" (or whatever
we finally get from PEP308) which we can't even write yet anyway.

There may also be introspection advantages, though I suspect that this
can lead to similar situations to the overloading issue in C++. That
said, Python is not statically typed so you don't declare the type of
intermediate results - most boolean results come from boolean
expressions, and these will naturally acquire the boolean type by
using the appropriate Python version.

Whether rare problems are better than frequent problems is debatable,
of course - rare problems tend to be more difficult to find and
understand, so the mere quantity-of-typing issue to fix the problem is
not always as serious.

As I said - experience will tell.

That said, I wish I hadn't mentioned it now. I wanted to counter Eriks
point because I find Aahz' point about standard spellings compelling
but Eriks point about full-fledged types much less so. But a
full-fledged boolean type is in no way harmfull and, given that it is
now part of Python, there is no point getting into a big debate about
its relative value.

Having a standard spelling (however it is implemented) is certainly a
Good Thing IMO. If there are benefits to having a full-fledged type
which stand the test of time, then respect to the people who had the
vision and put in the work to add them. In fact, either way, respect
to them for giving the full-fledged type the chance. My doubts are not
intended as criticism.

-- 
steve at ninereeds dot fsnet dot co dot uk




More information about the Python-list mailing list