[Python-ideas] `issubclass` shouldn't be raising exceptions for non-type inputs
fuzzyman at voidspace.org.uk
Mon Nov 29 00:26:08 CET 2010
On 28 November 2010 23:23, cool-RR <cool-rr at cool-rr.com> wrote:
> On Mon, Nov 29, 2010 at 1:21 AM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:
>> On 28 November 2010 22:37, cool-RR <cool-rr at cool-rr.com> wrote:
>>> `issubclass(1, list)` raises an Exception, complaining that `1` is not a
>>> class. This is wrong in my opinion. It should just return False.
>>> Use case: I have an object which can be either a list, or a string, or a
>>> callable, or a type. And I want to check whether it's a sub-class of some
>>> base class.
>>> So I don't think I should be taking extra precautions before using
>>> `issubclass`: If my object is not a subclass of the given base class, I
>>> should just get `False`.
>> Unfortunately it would be a backwards incompatible change. Currently
>> catching the TypeError from issubclass is a way of detecting that an object
>> *isn't* a type.
> Who is doing that?! What's wrong with something like `isinstance(thing,
> (type, types.ClassType))`?
It doesn't matter who is doing it (or why). If they are writing valid python
code we shouldn't break it for them. That's only my opinion - personally I
always write the guard and would *like* to see the change. I don't think
that's sufficient to break backwards compatibility in this way though.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas