PEP 285: Adding a bool type

[Ype Kingma]

Alex,

you wrote:
> 
> Ype Kingma wrote:
>         ...
> > The problem is that a lot of code has been written assuming 1/0 behaviour
> > of boolean values.
> 
> The "problem" is that behavior is VERY useful.  So, taking it out would
> reduce productivity (by a little) as well as making the language harder to
> teach (by a little or by a lot -- I used to think "by a little", Laura's
> post is making me thing it may well be "by a lot").
> 

I wasn't talking about removing this behaviour, although I don't like it.

I said:

	After having my head set straight on this by Martin v. Loewis
	(see the thread 'but not as int subtype') I concluded in favour
	of PEP 285, with the remark that what can in the future
	not be implemented using the special methods of bool and current
	standard types should be deprecated at the same time the PEP
	gets into force.

and:

	The only example of such code I know of
	is user implementations of __getitem__, ie. objects
	indexable with square brackets, that are actually indexed with bool arguments.
	When all such user code has been fixed, there is nothing in the way
	of a real boolean type that is not an int-in-new-hat.

by which I meant that _user_code_ implementations of __getitem__()
that will be receiving bool's when they are introduced might need a simple
fix.

About the remaining current 1/0 behaviour I said:

	If there were a real boolean type in Python this backward
	compatible behaviour can be implemented in the __add__, __radd__
	and other special methods of the numeric classes (see the language reference on special
	method names: http://www.python.org/doc/current/ref/specialnames.html).
	They would work by using the value 1 or 0 when encountering a boolean value.


> > This Something/Nothing feature is indeed very useful.
> > However, it is not part of the python language, it is part of the way in
> > which the standard types are implemented.
> 
> The Language Reference manual of the Python language disagrees
> with you.  E.g. at http://www.python.org/dev/doc/devel/ref/Booleans.html :
> 
> """
> In the context of Boolean operations, and also when expressions are
> used by control flow statements, the following values are interpreted
> as false: None, numeric zero of all types, empty sequences
> (strings, tuples and lists), and empty mappings (dictionaries).  All
> other values are interpreted as true.
> """

Thank you for pointing this out. I only read the contents of both parts
(the language ref and the standard library ref) and based my post on that.
I should have read the manual completely.

> This is the Python LANGUAGE we know and love -- the LANGUAGE
> Reference says so, and us Language Lawyers know that.  You want to
> change Python, that's one thing.  But don't tell us that this part of the
> Language Reference "is not part of the python language".

I do not want to change that part of the language. I tried to
say that the backward compatible 1/0 behaviour and
the Something/Nothing behaviour can be implemented in the special methods
of the standard types, even when a non int-a-new-hat bool would be added
to the language.

> > if something_there:
> >     ...
> > else: # nothing_there
> >     ...
> >
> > A real boolean is required to control the conditional branch.
> 
> If you say so.  In this case, since we DO "control the conditional branch"
> in the current version of Python, then we HAVE "A real boolean" whatever
> that may be (as defined by the language reference, see above).  Every
> value in Python is "A real boolean", since any can "control the conditional
> branch".

On which I also said:

	Since slices are also explicitly available, I'd like a real boolean
	to be available. It fits the language.

by which I meant:
Since a boolean is implicitly there, why not have it explicitly available.
Slices are much the same: they are 'almost' implicitly there,
but they are already explicitly available. (How often do you
actually need slices? I'd expect you to use bool more often
than that if you could.)

 
> > As I said, it's not in the language, it's in the standard types.
> > The millisecond is spent on the implicit derivation of a boolean
> > in the readers' head. The  interpreter does the same thing, although
> > faster.
> 
> There's no delay at all in my mind as I parse "if zebras:" -- there
> WOULD be if that had to carry excess verbiage (to get a "real",
> "pristine" boolean type -- which fortunately the PEP does not
> propose, thanks be).  There's no delay in the minds of students
> for which the Python something/nothing concept has 'clicked'.  I
> read Laura's point as it being crucial to make that concept click,
> and the existence of True/False being a substantial obstacle to
> making it click.

This 'concept click' comes from the consistency by which the standard
types map the Something/Nothing to the True/False needed as part
of the decision in the conditional jump in 'if' and 'while'.
They are so consistent that one can (and should) forget about what happens
in between and that it python decisions can be taught as Something/Nothing
without digressing to True/False.

> > After having my head set straight on this by Martin v. Loewis
> > (see the thread 'but not as int subtype') I concluded in favour
> > of PEP 285, with the remark that what can in the future
> > not be implemented using the special methods of bool and current
> > standard types should be deprecated at the same time the PEP
> > gets into force. The only example of such code I know of
> > is user implementations of __getitem__, ie. objects
> > indexable with square brackets, that are actually indexed with bool
> > arguments. When all such user code has been fixed, there is nothing in the
> > way of a real boolean type that is not an int-in-new-hat.
> 
> Do you propose to make your "real boolean type" non-hashable,
> so that it can't be used to index into a dictionary?  Can you please
> clarify the reason for *THAT*?

Off course I want the boolean constants to be hashable.
However indexing using boolean constants instead of
integers will break some user code that assumes it's argument is an
integer, see below.

> If you do NOT want to forbid usage of your newfangled booleans
> as keys into dictionaries, then you're at least using imprecise language
> in talking about "objects indexable with square brackets", since
> dicts are indeed thus indexable (and more generally so are all
> mappings).  Besides, would adict[True] be the very same dict entry
> as adict[1], or not?  If they aren't to be the same entry, then how do
> you propose to transition smoothly from a present in which they are
> to a future in which they are not?  If they are, you need hash(True)
> to be 1 and True==1 to hold (or else dicts would be seriously slowed
> down -- a pythonic nono! -- and user-coded mappings would have
> serious problems too), so SOME level of confusability must be kept.

In the other thread 'but not as int subtype', in the context
of user code implementations of __getitem__, I also said:

	Indexing a dict with both int and bool keys might involve some confusion
	when True is not 1 anymore. This case should be rare, however.

For standard types, ie. normal dictionaries there is no problem since
one can simply add the int() method call in the implementation of
__getitem__ of the standard dictionary for backwards compatibility.
User code trying to implement a dictionary will need a similar
fix as I pointed out above. I can only hope there is no more breakage in
user code.

> I think the best levels of confusability (interchangeability, polymorphism,
> name it as you will) between concepts are "all" and "none", in general.  If
> "all", the concepts are practically coincident even though there may be
> some _conceptual_ separation that has no reflection in practice; if "none",
> the concepts are utterly separate in practice even though there may be
> some _conceptual_ common ground.  Either of these is easy to teach.
> Middle-ground is harder to teach, though there may be very good (real,
> practical -- or even philosophical) reasons to pay this price in some cases.
> 
> I don't think "none" is feasible here, and I much prefer the current status
> quo of "all" anyway.  The PEP has a lot of confusability (thanks to
> inheritance and True==1, perhaps even to str(True) being '1' depending on
> how that's decided); your proposal has very little (but, I think, not
> "none" -- see above).  So there's a conceptual price to pay, as well
> as a pragmatic one (low for the PEP, high indeed for your proposal).  And
> I _still_ don't see that the claimed benefits would actually amount to a
> substatial hill of beans.  I have nothing against beans, particularly in my
> soup, but they seem to come too dear here -- for a price I might perhaps
> be willing to pay for good steak, if that.  High price, tiny benefit, my
> personal mental scales slant more and more towards a 'nay'.

I'm afraid I'm not understanding you completely, but this may due
to the moment of the day here.

My conclusion (proposal?) from the other thread was in favour of the PEP,
with the remark that some user code that would break when bool does not
inherit from int anymore should be deprecated and fixed, in order to allow for a 
non int-in-a-new-hat bool in the future.
I think all the python system code can be fixed to withstand the change from
bool as int-a-new-hat to bool 'not as int subtype'. By python system code
I mean the C code implementing CPython and the Java code implementing Jython.
(The special methods of the standard types in this code would need
to add int() calls and evt. type tests for bool to obtain the backward
compatible 0/1 behaviour of bool.)

> > In fact this could be seen as a good example of the usefulness of
> > object orientation: it allows separation of concerns to the extent
> > that the standard types are documented separately from the language.
> 
> But that's NOT what the Python Language Reference chooses to do
> for "Booleans" -- it documents them right smack in the middle of
> the Language Reference itself.  So?

Even though I still have not read the manual completely I would (and did)
expect it to be possible that this aspect of the standard types
be defined in the library reference instead of the in the language
reference.
However, if this were the case, Laura might not have come up with
the Something/Nothing python way, so hats off to the manual makers.

Regards & thanks,

Ype

-- 
email at xs4all.nl