[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/)