Python 3 isinstance

[Carl Banks]

On Jan 15, 3:35 am, Duncan Booth <duncan.bo... at invalid.invalid> wrote:
> Terry Reedy <tjre... at udel.edu> wrote:
> > Lambert, David W (S&T) wrote:
> >> Overly terse.  I do mean that this is illegal:
>
> >> isinstance(s, {str, bytes})
>
> >> tuples have order, immutability, and the possibility of repeat items.
>
> >> A set is most reasonable in a mathematical sense.
>
> > I agree.  However, isinstance predates set.  Hence the status quo.
>
> There is another reason which nobody has mentioned, and which might make it
> tricky to do a good implementation that does accept sets.
>
> The second argument to isinstance or issubclass is a classinfo where a
> classinfo is either a class or a tuple of classinfo. This makes it easy to
> group related types: you can just combine existing groups of types together
> without having to flatten tuples. The immutability of tuples guarantees
> that you cannot create a recursive structure this way.
>
> If you allow sets then the code which traverses the classinfo has to
> protect itself against the possibility of an infinite recursion.
>
> The same argument also applies to exception handlers which also accept a
> type or a tuple of things they accept.
>
> Of course you could allow either an existing classinfo or a set of types,
> but not allow the set to contain anything other than types. That would
> still prevent recursion but means you have to be stricter about knowing
> what you are combining. That probably wouldn't be a bad thing if everyone
> used sets consistently but I suspect would be messy if introduced at this
> stage.

I don't see what the big deal is.  Right now isinstance accepts a type
or a tuple of types.  The code could be changed to allow a type, or
any iterable the returns types (wherein every items of the sequence is
required to be a type).  What's messy about that?


Carl Banks