On Mon, Nov 29, 2010 at 1:26 AM, Michael Foord email@example.com:
On 28 November 2010 23:23, cool-RR firstname.lastname@example.org wrote:
On Mon, Nov 29, 2010 at 1:21 AM, Michael Foord <email@example.com
On 28 November 2010 22:37, cool-RR firstname.lastname@example.org 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.
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?