PEP 285: Adding a bool type

[Martin v. Loewis]

Alex Martelli <aleax at aleax.it> writes:

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

Nah, that is hardly the same thing. With the PEP, nobody *has* to do
anything; existing programs will continue to work just fine (with very
very few exceptions). If people want to return 0 when they mean False
- fine.

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

I disagree. Somebody could use the language (with the change) and
believe booleans are completely unrelated to numbers, and would rarely
find this view incorrect - at which time you'll need to explain that
booleans interact with numbers in a certain way.

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

While it is true that False can be used everywhere, it doesn't mean it
should be. Use booleans if you want to express the value of a
predicate; use integers if you want to count things.

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

No. If the goal had been to change the canonical spelling, two new
builtins would have been sufficient. The goal was to create a new type
for those, in addition to the new spelling.

> '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?

Indeed. I wonder how often the warning would trigger, though. I'd
expect that people very rarely compare the result the got from a
predicate to something else.

> > 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 would indeed have the warning produced for all occurrences of True -
perhaps a different warning if the parser can tell that True is bound
at module scope. This is essentially what pychecker does in many
similar cases, and Guido is in favour of moving some of the PyChecker
warnings into the interpreter.

There would be an option to turn off parser warnings, of course.

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

These are different issues, though: those voices want to ban
interactions between booleans and numbers; I want to ban binding of
names that are also builtins (starting with None, True, and False).

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

Ok, so the problem is more involved. I would suggest to produce the
warning for 'is True', but not for 'True is' ... (I'm not sure whether
I mean this seriously :-)

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

I'm not sure how big this problem is: it should be easy to add
bool-loading function to Python installations for use with Python
before 2.3. Packages that need to support cross-version pickling could
incorporate such a feature.

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

This is a transitional issue. It may matter, but it may not matter
enough to take action - depending on the application. An application
that worries about cross-versioning pickling (presumable across
versions of its own software as well) will have to take efforts
already; avoiding to dump booleans will be a minor complication only.

> So _why_ pay the price -- not a huge, world-racking one, but still
> one nevertheless?

I could repeat the rationale of the PEP here, but I guess the question
was rhetoric.

Regards,
Martin