Home Original page

[Python-ideas] `issubclass` shouldn't be raising exceptions for non-type inputs

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

Michael


>
> Ram.
>



-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20101128/4781da3e/attachment.html>
More information about the Python-ideas mailing list