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