[Python-Dev] For review: PEP 285: Adding a bool type

Guido van Rossum guido@python.org
Fri, 08 Mar 2002 15:39:36 -0500


> Question: what will happen with all the return 1 or return 0 etc 
> in the std lib and in user code and in the inline doc
> and docs?

Ideally they would have to be changed into True and False, but there's
no hurry -- 0 and 1 will continue to be valid as truth values too.

> (I have found 167 return 1 in the std lib and 176
> return 0,
> and also code like this
> 
>     if os.name == 'mac':
>         # The macintosh will select a listening socket for
>         # write if you let it.  What might this mean?
>         def writable (self):
>             return not self.accepting
>     else:
>         def writable (self):
>             return 1
> 
> which unchanged will define a bool vs int
> function.)

A job for PyChecker! :-)

> There are function in the std lib that return 1 on success,
> 0 on failure. Are there function that do the contrary
> like unix calls? Should these return True and False now.
> Maybe not?

I doubt there are any functions returning 0 for success and -1 for
failure, but if there are, they should not be changed.

> In distutil code I have seen at least
> one function documented as returning 'true'
> on success.

Another reason to introduce a Boolean type. :-)

> Then there are really predicate function/methods,
> they should probably be changed?

Yes.  I hope that most of the C code goes through some easy choke
point that makes it simple to change a lot of these at once
(e.g. using Py_True and Py_False).

> but that means that the situation for the
> user will be *ideally* less muddy only when all
> the code uses True/False everytime it makes sense,
> and not 1/0.

Yes, it will take time before everything is converted.  That's why we
must be careful to decide if we really want this.

--Guido van Rossum (home page: http://www.python.org/~guido/)