PEP 285: Adding a bool type

[phil hunt]

On Sat, 30 Mar 2002 20:05:35 +0000, phil hunt <philh at comuno.freeserve.co.uk> wrote:
>On 30 Mar 2002 01:36:43 -0800, Paul Rubin <phr-n2002a at nightsong.com> wrote:
>>Guido van Rossum <guido at python.org> writes:
>>>     Dear reviewers:
>>> 
>>>     I'm particularly interested in hearing your opinion about the
>>>     following three issues:
>>> 
>>>     1) Should this PEP be accepted at all.
>>
>>I don't see much need for it.
>
>Nor do I. Python works OK as it is, asnd this proposal adds nothing 
>new semantically (because bool must act the similarly to int, for 
>compatibility). The only advantage I see is that code is slightly 
>more self-documenting, e.g.:
>
>      return True
>
>instead of:
> 
>      return 1

I've gone through some of my herbivore code, looking to see where 
I've used 0 or 1 as a boolean. Example 1:

debug = 0  # debugging this module?

Frankly, if that is unclear to anyone, they are not cut out to be a 
programmer. Bear in mind that most non-programmers are aware of the 
0/1 paradigm for boolean values: it appears on much electrical 
equipment.

Example 2:

CONFIG_DEFAULT_VALUES = {
   'dest': "file:mess_out_%(ix)s",
   'log': 1,
   'logItems': ["i", "ip", "o", "op", "cmd", "comment"],
   'logMessItems': ["From", "To", "Cc", "Bcc", "Subject", 
      "Message-Id", "X-Herbivore"],
   }


Here, the 1 value for 'log' means turn on logging, so could 
naturally be replaced by a boolean. These are default values for the 
config file; in the file they will look like:

log = 1

The file is executable Python code, and so could naturally be 
changed to:

log = True

if it is unclear. But (1) it isn't unclear, since the default config
file contains a comment before each config variable, saying what it
means -- and anyway there will be a GUI config tool for Herbivore,
and (2) Herbivore, by design is required to be easily installed;
specifically, the user shouldn't have to upgrade to a newer version
of Python, so I wouldn't be able to use booleans for a long time
after they'd been added.

So there would be no benefit for me at least in adding this feature.

Now we turn to the other side of the coin: would this proposal cause
problems. Contrary to my initial post, I see one place where it
might well do. Consider a program that communicates with instances
of the same program on other machines by way of Python data 
expressed as repr() strings. Each instance of this program will work 
on its own. Each instance will continue to work if Python on that 
machine is upgraded to a post-boolean version. But the upgraded and 
unupgraded will no longer be able to talk to each other if there are 
any boolean values being passed around. This could well be a 
hard-to-track-down error, since both versions will continue to work 
perfectly well on their own.

So because there seem to be few advantages, potential disadvantages, 
and because the proposal adds unnecessary complexity to the Python 
language in return for some superfluous syntactic sugar, I dislike 
this proposal.

-- 
<"><"><"> Philip Hunt <philh at comuno.freeserve.co.uk> <"><"><">
"I would guess that he really believes whatever is politically 
advantageous for him to believe." 
                        -- Alison Brooks, referring to Michael
                              Portillo, on soc.history.what-if