[Python-checkins] python/dist/src/Objects abstract.c,2.110,2.111 classobject.c,2.164,2.165

[Walter Dörwald]

Guido van Rossum wrote:

>>Modified Files:
>>	abstract.c classobject.c 
>>Log Message:
>>Enhance issubclass() and PyObject_IsSubclass() so that a tuple is
>>supported as the second argument. This has the same meaning as
>>for isinstance(), i.e. issubclass(X, (A, B)) is equivalent
>>to issubclass(X, A) or issubclass(X, B). Compared to isinstance(),
>>this patch does not search the tuple recursively for classes, i.e.
>>any entry in the tuple that is not a class, will result in a
>>TypeError.
> 
> 
> Why the latter limitation?  Now we have an inconsistency:
> 
>   >>> isinstance(1, (long,(float,int)))
>   True
>   >>> issubclass(int, (long,(float,int)))
>   Traceback (most recent call last):
>     File "<stdin>", line 1, in ?
>   TypeError: issubclass() arg 2 must be a class or tuple of classes
>   >>> 

We had an inconsistency before ;):

 >>> isinstance(1, (long,(float,int)))
1
 >>> issubclass(int, (long,(float,int)))
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: issubclass() arg 2 must be a class

To make a recursive tuple argument work, PyObject_IsSubclass()
would have to call itself recursively. This would mean, that
on each call redundant checks for classness would be made.

I'd consider the abillity to handle recursive tuples an
unfortunate side effect of the isinstance() implementation.

If we want isinstance() and issubclass() to be as similar as
possible, we can either deprecate recursive tuples for
isinstance() or allow them for issubclass().

Unfortunately recursive tuples have been documented in
Doc/lib/libfuncs.tex, so we can't silently remove them.

I wonder what the use case for recursive tuples is.

Bye,
    Walter Dörwald