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

[Guido van Rossum]

> That's the main argument for adding a boolean *type* to
> the language. We already have the singletons...

In C, not in Python!

> mxODBC in SQL binding mode. Some databases only allow
> passing in strings, so mxODBC has to call str(obj) to
> pass the object stringified to the database.
> 
> This works just fine with Py_True and Py_False, since DBs
> know that 1 and 0 are true and false. I'm not sure how
> well 'True' and 'False' would work here, ODBC doesn't say
> anything on these values if used in the C API, in fact
> it doesn't have a native BOOLEAN type, just a BIT.

OK, so you may have to change one line in one module.

> Perhaps you could clarify the need for these new
> __str__ and __repr__ values ?!
> 
> I'd be happy with repr(True) giving me 'True',
> but not str(True).

It just seems to make more sense if booleans print as True and False.
But if that really is going to be the only place where things break,
I'm willing to reconsider this.

> No. The point is that printing truth values up to now has
> always resulted in '0' or '1'. You are about to change that
> to 'True' and 'False'. This can create a l10n issue in 
> existing applications.

An application that prints the digits 0 or 1 to mean true or false
doesn't sound very user-friendly to me either.  I'm not worried that
we'll get actual complaints from people that this broke their program.

> It may also cause applications which write out boolean
> data this way to fail, e.g. report generation tools,
> XML generators, database extraction tools, etc...
> Just think of code like this:
> 
> 	print '<boolean value="%s">' % (x != 0)
> 
> (It's not like I'm running out of arguments :-)

We'll see. :-)

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