GvR> I'm currently +1 on introducing names for abstract base GvR> classes *and* extensing isinstance()'s API.
I'm worried about the abstract base class idea, because it might lead us down a path of having a complicated class hierarchy in order to provide completeness.
Yes, that's a danger. I'm currently thinking about adding a small number of abstract base classes, corresponding to the groups of basic concrete data types in Python: numberbase, integerbase, sequencebase, stringbase, mappingbase, filebase. And I'm not even sure of these! Practically, I only see a use for stringbase and integerbase, since these have two concrete subclasses; the others are just to make the OO zealots happy. :-)
E.g. should "strings" be a sequencebase, as well as a stringbase?
Yes. Any way you can think of that checks for a "sequence" will consider strings to be sequences, unless you make explicit exceptions.
And what does a sequencebase /mean/?
Whatever I want it to mean. :-) The latest code for sequence-ness tests for sq_getitem != NULL, and I think that's reasonable.
Will we push to try to include protocols/interfaces into this mix, so that we'll end up defining abstract classes for all the deep-mojo interfaces?
I'd prefer not to.
Maybe we'll want to have abstract base classes for file objects so things like file and StringIO's can have them as a common base class?
That's currently hard. I don't think we can make StringIO a new-style class, and classic classes can't inherit from new-style classes (not even abstract ones).
In any event, I think the isinstance() extension is a simple, clean, and (mostly :) uncontroversial change, so I'm also +1 on doing that now.
Yes.
Adding a set of abstract base classes and hooking them up with the existing concrete data types seems much murkier to me, and of greater long range impact, so I'm -1 on the idea, at least until it gets PEP'd.
I'm at best +0 myself -- I have more thinking to do... I've *mostly* convinced myself that stringbase is a good idea. But even there, the existence of the buffer API makes the semantics slightly murky. --Guido van Rossum (home page: http://www.python.org/~guido/)