PEP 285: Adding a bool type

Martin v. Loewis martin at v.loewis.de
Mon Apr 1 08:24:39 EST 2002


Alex Martelli <aleax at aleax.it> writes:

> 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
will appreciate the increased readability if the builtins keep their
names.

> f. the claimed conceptual benefits in easing the lives of programmers and
> newbies in particular I consider as illusions.  Programmers want booleans
> 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. Programmers that are used to booleans from previous
languages might well find their lifes easier. Even people that you
have not seen sad might enjoy this enhancement - they just did not
know what they were missing :-)

> 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.

In the past, untruth could be spelled in many ways (0, None, (), ...);
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).

> 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...)

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

> 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).

> 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.

Regards,
Martin



More information about the Python-list mailing list