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

M.-A. Lemburg mal@lemburg.com
Fri, 08 Mar 2002 19:29:30 +0100

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 PyTrue and PyFalse 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/