PEP 285: Adding a bool type

Laura Creighton lac at strakt.com
Wed Apr 3 13:15:50 EST 2002


[Mark McEahern]
> [Laura Creighton]
> > That is more strongly worded then I would make it; I only think that
> > deciding that a function should be compelled to return only one of
> > two values requires long and careful deliberation.  This is because it
> > is likely that some day you will wish that you could provide more
> > information than this allows.  isinstance is a good example
> > of this. I would be pleased if isinstance returned more useful info
> > than just yes/no, such as : 0, no inheritance; 1: direct instance of the
> > requested class; 2: instance of a subclass of the requested class.
> > 90% of uses would still be yes/no, but this would be fine, and you would
> > get the extra information when you needed it.
> 
> That's an eye-opening and thoughtful response. 

Thank you very much. 

>                                                All I'm saying is that this
> design philosophy is completely orthogonal to the value of PEP 285.

Certainly, but if I understand you correctly, all you want is a 
consistent thing called True and False which you can use.  I already
proposed a different way to get that, which doesn't involve inventing
a new type, which looks like a bool and behaves like an int. That is
what adding True and False to __builtins__ would do.  And I
explicitly did not discuss the value of adding a new type which looks
like a bool and behaves like a bool, which would be another way to
get this benefit.

> 
> Further, if I wanted such a function, I wouldn't call it isinstance().

Yes.  This is what the 'some day' is about.  As consider extending your
functions you frequently are less than perfectly happy with the name that
you (or somebody else) chose, sometimes years ago,  before you had your 
current insight, or new need.  Then you get to decide if it is better to 
write a new function or extend the one you have got and live with the
less than perfect name.  If you write a new one, you get to decide if
you should deprecate the old one - or remove it entirely.

> 
> Cheers,
> 
> // mark

Laura Creighton





More information about the Python-list mailing list