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

[M.-A. Lemburg]

Guido van Rossum wrote:
> 
> > > But this is the whole point of introducing a new type rather than
> > > simply defining True as 1 and False as 0!
> >
> > That's not how I read it: making bool a type would allow type
> > checks to be done and this is a *much* more important feature
> > to have than some different str(obj) output.
> 
> Depending on your POV, yes.
>
> > There are many situations when doing RPC or interfacing with
> > other systems such as databases where a type check for
> > booleans is needed.
> 
> Agreed, this is a nice additional advantage.

That's the main argument for adding a boolean *type* to
the language. We already have the singletons...
 
> > Currently, this can be done by simply using the already
> > existing Py_True and Py_False which are exposed at
> > Python level through (1==1) and (1==0) and we should not
> > break this scheme. '%s' % True must continue to
> > deliver '0' otherwise you'll end up breaking interfaces
> > which rely on this (such as database modules).
> 
> That's a good question.  Don't databases have a separate Boolean type?

Yes and currently it is encouraged to use Py_True and
Py_False on DB module output and the truth test on DB module 
input.

> Is there really code out that relies on this? 

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.

> The code would have to
> assume that the boolean argument is already normalized to being
> exactly 0 or 1; a generalized Python truth value wouldn't work.

Right.
 
> I can provide a real implementation next week, and we should have
> plenty of time to find out how much it breaks.

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).

> > There's also another issue here: "True" and "False"
> > are English words, "0" and "1" are language neutral.
> 
> Methinks you are getting desperate for arguments here. :-)  Or should
> we also remove "if" from the language?

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.

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 :-)

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/