[Python-Dev] Need a way to test for 8-bit-or-unicode-string

[Guido van Rossum]

>     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/)