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

cool-RR cool-rr at cool-rr.com
Mon Nov 29 00:45:33 CET 2010

On Mon, Nov 29, 2010 at 1:26 AM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

> 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

I guess it depends on how many people do that. Doing `issubclass` and
excepting `TypeError` is a very convoluted way of checking if something is a
type. I think that the kind of person who would write that code is not the
kind of person who would care to port their program in Python 3.x.

Also, isn't it possible to break backwards compatibility on such things by
deprecating it in one release and changing it in the next?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20101129/ce3c7d54/attachment.html>

More information about the Python-ideas mailing list