[Python-Dev] For review: PEP 285: Adding a bool type (original) (raw)

David Ascher DavidA@ActiveState.com
Fri, 08 Mar 2002 11:54:10 -0800

It is commonly seen as a small wart. While the wart is easy to work around (I've seen lots of code defining constants True and False or variations), what's missing is a standard way so everybody can do it the same way.

That's easy. That problem can be dealt with by defining True and False as built-in constants with values 1 and 0 respectively (while you're at it, make None read-only =).

> 2) "it helps with things like RPC protocols that may prefer to encode > Booleans differently from integers." > > That is a real issue except that it seems to have been solved relatively > well by all of the language bindings so far. IIRC, there are some > awkward situations in Jython if you explicitly want to send a boolean to > a polymorphic function, but that's an edge case.

I didn't invent this argument; Marc-Andre thought it would be helpful. I see it as a mild argument at most. But it's useful that in situations where a receiver would like to distinguish Booleans from ints, you can now do it.

Agreed. I also agree w/ the mildness of it.

> 3) "It's useful to be able to tell from a function result that the > outcome has Boolean semantics" > > This is intriguing. I can't think of a case where the current integer > return values have caused me problems or concerns that weren't solved by > simply understanding what the function was about. What use case did you > have in mind?

When showing people comparison operators etc. in the interactive

>>> a > b 1

vs.

>>> a > b True

and:

>>> cmp(a, b) 1 >>> cmp(a, a) 0

Which really seems to be the key issue, both as a positive (your argument) and as a negative (MAL's posts).

I wonder if the str()/repr() distinction or % formatting codes could help break the logjam. Probably not.

I'm still not convinced that the disease is worth the cure, but I'm open-minded =).

--david