PEP 285: Adding a bool type

Alex Martelli aleax at aleax.it
Wed Apr 3 02:39:23 EST 2002


David Eppstein wrote:

> In article <pTpq8.53356$S52.1844974 at news2.tin.it>,
>  Alex Martelli <aleax at aleax.it> wrote:
> 
>> > yes. but a real bool could be introduced as module for now (for the RPC
>> > and marshalling people that need one) i think its not needed otherwise
>> 
>> A standard library module sounds good.  Or maybe it could go into
>> operator.
> 
> So you'd be happy with a Boolean class, as long as it isn't convertable
> to integers and none of the standard operators are changed to return it?

I don't think it would do any damage if int(x) accepted an x of such
a class, just as it accepts, e.g., an x of type str.


> That doesn't seem very nice either from the aesthetic purity-of-design
> point of view (non-convertable is more pure than convertable maybe but

There's no "loss of purity" in int('23') returning 23, so why should there
be any in, say, int(Boolean.True) returning 1?

> (Booleans would be too cumbersome to use except in unusual situations).

They'd come in handy for those peculiar situations where you HAVE
to distinguish between integers and booleans, basically only when you are
interfacing some external subsystem such as a DB or RPC system that
does require such distinctions (as opposed to ones that _don't_ support
it, such as, we're told, MySql).  And, by not affecting built-ins, 
operators, etc, they wouldn't be in the way in everyday life, nor, most
particularly, would they impose conceptual burdens on teaching Python.


> In comparison the actual PEP is similarly not-pure but gives better

Far more "not-pure", since the PEP requires _implicit_ conversion (or
else tons of code would break).

> expressivity and possibly adds minor functionality (ability to make code
> that behaves differently for ints and for bools, just like now you can

It would be quite possible to distinguish between int and Booleans if
you needed to, even if Booleans came from a specific module rather
than from builtins, of course.  Such a need is a very rare issue, thus
it should not be allowed to get in the way for everyday usage.

> behave differently for lists and for tuples even though they are
> interconvertable).

[1,2]+(3,4) raises an exception.  All sequences are convertable
_explicitly_ (tuple([1,2]) and so forth).  But very rare needs, such
as homogeneous arrays, are quite properly shunted off to their
own standard modules, they DON'T get in the way of our common
usage of the general builtin sequences.


Alex




More information about the Python-list mailing list