[Python-Dev] Evil isinstance()

[Guido van Rossum]

> Good point, but... if a user-defined class raises TypeError when I try
> to add 0 to an instance thereof, then I _can't_ use said instance as a
> number... whether because of a bug in said class, or because said class
> is not intended to be number-like, I *can't* use it, so I won't.  I will
> then similarly discover I can't use it as a string either, and end up by
> raising TypeError because by hypothesis I don't know what else to do.

But hiding the true source of the error.  If there was a bug in the
user code, I'd like to hear about *that*, not about your inability to
deal with it.  Otherwise, why don't you just use a bare "except:"
clause <sarcastic wink>?

> This doesn't seem so much of a problem to me to warrant rejecting
> perfectly good numberlike and stringlike classes' instances, by
> isinstance'ing away.

Agreed, and I think the solution ought to be sought in asking a
question involving hasattr().

> __int__ may well lose information -- that's how it's defined, after
> all -- but having it might be taken as one possible test of
> numberhood

Unfortunately, non-numeric types are known to implement __int__ for
some obscure purpose.

> > This leaves me in the uncomfortable position that I don't know
> > what to recommend. :-(
> 
> In your shoes, I'd recommend PEP 246 -- since, if I were in your
> shoes, I'd have approved it long ago.  (We don't need to have
> interfaces as a distinct concept from types/classes to approve PEP
> 246 -- any types can serve as 'protocols' to make PEP 246 a
> reality).  It would offer a very good solution to problems in this
> category, in my opinion.

Maybe you can summarize it again using a different vocabulary?  I find
that PEP very hard to read, but I recall liking your informal
explanation of it.  Unfortunately I don't recall enough of that
explanation to go ahead and approve the PEP (I have no idea what
effect that would have).

--Guido van Rossum (home page: http://www.python.org/~guido/)