[Python-Dev] bool conversion wart?

[Josiah Carlson]

Jordan Greenberg <jordangreenberg at gmail.com> wrote:
> Guido van Rossum wrote:
>  > How would this change be helpful? I'm utterly mystified by these
>  > suggestions that bool would be more useful if it didn't behave like an
>  > int in arithmetic.
> 
> I don't think anyones really saying it would be more useful, it 
> obviously wouldn't, since like Greg said, it wouldn't work in mapping 
> access or set membership like it does now. I think it would be more 
> readable though, since thinks like this:
>   >>> True in set([1])
> True
> 
> or that 5+True is equal to 6 aren't necessarily obvious to someone who 
> doesn't know that True evaluates to 1.

Maybe, but 30-some years of C semantics and another 15 years of Python
semantics die hard.  a==b for builtin types used to return 1 or 0, now
they return True or False.  Changing such semantics because some users
haven't ever used C or older Pythons would be a bit like changing 'def'
to 'fcn' because some users have never used 'def' to define a function. 
Learn the semantic and move on.


> It is elegant to embed bool in int, but to me it screams C. To me, it 
> makes more sense to use an int if you want an int, and to reserve 
> boolean for logic.

You say "screams C" as if it were necessarily a bad thing.  Certainly C
isn't a perfect language (which is why I use Python), but there are many
reasons why I (and others) use (or not) C, but I can just about
guarantee you that the semantics of booleans in C *help* rather than
hurt its adoption.

>  From an elegance/usefulness standpoint, maybe bool should evaluate to 0 
> and 1. But IMHO, it would eliminate some gotchas and improve readability 
> if it didn't.

You are, of course, entitled to your opinion.  From what I understand,
there is perhaps one major "gotcha" in the current semantics:
bool(str(<obj>)) isn't correct for anything except for '' and u''.  Then
again, that isn't a guarantee with str or bool (or list, tuple, dict,
deque, set, etc.)

 - Josiah