On Jan 15, 3:35 am, Duncan Booth <duncan.bo...@invalid.invalid> wrote:
> Terry Reedy <tjre...@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
--
http://mail.python.org/mailman/listinfo/python-list
