PEP 285: Adding a bool type

[Alex Martelli]

Martin v. Loewis wrote:
        ...
>> b. The hoped-for uniformity of notation won't happen -- we've already
>> seen on these threads people who want every constant to be uppercased
>> (to make it 'stand out') and so will use TRUE=True etc anyway.
> 
> That won't happen. People don't dare rename builtins, normally, and

Maybe it won't happen, but one poster on this thread _has_ said he
will do it -- if you claim he's lying, take it up with him.  Note that we're
not talking about "renaming" built-ins, just adding "synonyms" (binding
_extra_ names to the same object, without removing previous ones).


>> iff they're used to them from previous languages -- I've never seen
>> people used to (e.g.) APL, good old (uncommon?-) Lisp, or (dare I say it)
>> Perl, feel sad and deprived by the lack of booleans in their respective
>> languages.
> 
> That does not prove the claimed conceptual benefits as
> illusions. 

No proof (has any _proof_ ever been brought on this thread -- or just
about any?!), just an indication.  Note that those people are hardly
monolingual (I've met _once_ a person whose _only_ programming
language was APL, and I still recall it as a surprise, for example) -- they
are also quite likely to have experience of other languages such as
Fortran-IV, which did have 'LOGICAL'.

> Programmers that are used to booleans from previous
> languages might well find their lifes easier. Even people that you

In the same sense as they might well find their lifes easier if suddenly
they had to start decorating their Python programs with deuced braces
or BEGIN/END to indicate block structure -- they might find the
familiarity comforting.  It would still be a substantial mistake for Python
to give up to that perennial pressure, despite the minor advantages
(familiarity for Python-newbies coming from other languages, easier
life when embedding Python source in environments that may not respect 
whitespace or e.g. reading Python sources on the phone) because the
disadvantages would dominate.

> have not seen sad might enjoy this enhancement - they just did not
> know what they were missing :-)

This presupposes monolingual programmers, ones without exposure
to e.g. Fortran IV or Pascal.  I don't think that's typical at all of users
of languages such as APL or Perl.


>> Which leads me right onto disadvantages of the PEP -- because that's
>> the main one I see: extra conceptual load in teaching the language.  "0
>> can be spelled either 0 or False" with subtly (but generally
>> irrelevantly:-) different consequences...
> 
> 0 cannot be spelled False. 0 is spelled 0 (or perhaps 00, or 0x0). 0
> is a integral number, False is a boolean. These are different things.

No they're not: they're DISTINCT (is not) but NOT *different* (!=) -- not
even as 'diverse' as, say, 0 and 0.0, since there are quite a few cases
where you may use the former and not the latter (such as indexing) but
part of the PEP's claims is that (string representations apart) there will
be essentially no cases in which 0 is acceptable and False isn't (so, by
the "walk like a duck" principle, the distinction becomes rather vague --
and by that much harder to teach, and to use appropriately).

The point is: given any function named iswhatever, you may get from
it two different results when the question (predicate) is answered in
the negative -- False, if it's a function from the Python libraries, a
recently-coded function which respects the new 'bool', or an old function
which happens to use Python library functions (and operators) whose
result type has been changed -- 0, for an old function which happens
to have an explicit return 0.  No matter, because -- except for string
representations, basically -- the distinction is almost guaranteed not to 
make a difference.  So, you do have to learn about the distinction -- it
IS an extra conceptual load in teaching the language -- because you
MIGHT come upon a string-representation and need to be aware of
what will come up; but for almost all uses the distinction won't matter.

I think teaching this as alternate ways of *spelling* equal (but distinct: 
==, and essentially interchangeable in use, but NOT 'is') values will be
the least of evils.  The focus on spelling is sensible, because the string
representation (either str or repr or both -- I'm still not sure of how
Guido will decide that) makes up most of the difference.  There is, as
you say, a type distinction too -- but it's carefully designed to be as
irrelevant as possible... existing isinstance won't show that distinction,
only horrid type(...) == type(...) kinds of constructs will.


> In the past, untruth could be spelled in many ways (0, None, (), ...);

0 is (2.2 is still present, not yet past) the canonical way to spell 
untruth: it's what 'not', 'is', 'in', comparisons, and all standard library 
iswhatever's return -- including operator.truth, of course.

> with the PEP, you can say "untruth is spelled as False". You still
> need to explain that other things "count as false" also, but the
> proper spelling becomes "False" (whereas 0 served this position only
> by convention).

Exactly the same set of objects (plus the new object False, that's ==0
anyway and can be used just about wherever 0 can be) "count as
untrue".  The "by convention" status of the canonical spelling for untrue
still holds, except that you want to change the convention to the new
object which exists solely for the value of changing that canonical
spelling, more or less.  That canonical spelling is still the value returned
by 'not', 'is', 'in', and so forth -- exactly the same 'happenstance' (ha)
which gives its present canonical spelling its current status.


>> I've wasted too much of my life trying to explain to people why they must
>> NOT code "if some_condition==True:" or the equivalent thereof in various
>> languages, but just "if some_condition:".  The "== True" appendix,
>> useless at best, often damaging, seems one of the most natural errors by
>> newbies.
> 
> That is a problem. Perhaps comparing booleans and non-booleans for
> equality should cause a warning (for that matter, perhaps even
> comparing booleans and booleans should cause that warning...)

'if x == y:' should cause no warning, of course -- it's a general, perfectly
good polymorphic usage.  Why should the user have to silence warnings
or break the smoothness of polymorphism to ensure against x, or y, or
both being of this newfangled bool type?

> More realistically, the *parser* should emit a warning if it sees the
> name True used in such a context.

...assuming the parser can determine at parse time that True stands
for the built-in value at that point -- or do you want to give True an
exhalted semi-keyword status, beyond that of, say, None, a dignity that 
will produce frequent warnings if you rebind that identifier e.g. in a local
namespace?  I know 'slippery slope' arguments are disliked around
here, but both this exchange and the various voices raised in clamor
towards 'stronger, purer booleans' suggest to me that PEP 285's own
slope may be slippery indeed.


>> In Python I was blessedly spared that waste of teaching time.  If the PEP
>> is approved, I'll be back to wasting that time and effort (perhaps more,
>> given how seductive "is True" will appear to many newbies...!).
> 
> Fortunately, "is True" won't be much worse than "== True" (except when
> you have 1 on the other side).

No, but it's one more warning-case you have to propose (and how else
will one check for the wonderful new objects' identities if 'is True' 
warns?! by twists and turns of isinstance checking for bool then int()
and == checking for 1...?!).  And 'is True' is very newbie-alluring: a
true 'attractive nuisance' (in more than one meaning of the phrase).


>> And what happens to other forms of output, such as marshaling and
>> pickling -- does the bool or int nature of a 0 or 1 get preserved or
>> lost in a round trip?
> 
> That's a good point: booleans should round-trip when pickling. I guess
> it is a bug in the PEP that this hasn't been spelled out.

If they do round-trip, then, it seems to me, we get a 'gratuitous'
incompatibility of pickles produced by 2.3 wrt 2.2 programs trying to
read them -- one more annoyance (and not a very attractive one either,
this time) to weigh against the claimed benefits (miniscule when at
all present, it still seems to me).  And of course old pickles will give
0 and 1 so that much work will be needed to reconstruct them into
False and True when appropriate *IF* it matters at all if something
is True or 1.

And if it doesn't matter at all, then why bother introducing PEP 285
at all?  I suspect a mixture of objects, some recently loaded from old
pickles and not updated yet so their attributes are 0 and 1, some
newly built so their attributes are False and True, and some in a
half-way stage (recently loaded or deepcopied from old pickles, but
partly modified/updated) with some 'boolean' attributes actually at
0 or 1, others at False or True -- all of such soup will probably work
pretty well apart from utter display anomalies if some of the objects
are ever converted into string representations.  So _why_ pay the
price -- not a huge, world-racking one, but still one nevertheless?


Alex