This discussion appears about over, but I haven't seen any solutions via inheritance. Other languages that lack true interfaces use abstract base classes. Python supports multiple inheritance. Isn't this enough?
I haven't given up the hope that inheritance and interfaces could use the same mechanisms. But Jim Fulton, based on years of experience in Zope, claims they really should be different. I wish I understood why he thinks so.
If the basic types are turned into abstract base classes and inserted into the builtin name space, and library and user-defined classes are reparented to the appropriate base class, then isinstance becomes the test for category inclusion.
A partial example:
class FileType(): def __init__(*args, **kwargs): raise AbstractClassError, \ "You cannot instantiate abstract classes"
def readline(*args, **kwargs): raise NotImplementedError, \ "Methods must be overridden by their children"
Except that the readline signature should be shown here.
All "file-like" objects, beginning with file itself and StringIO, can extend FileType (or AbstractFile or File or whatever). A function expecting a file-like object or a filename can test the parameter to see if it is an instance of FileType rather than seeing if it has a readline method.
Type hierarchies could be obvious (or endlessly debated):
Endlessly debated is more like it. Do you need separate types for readable files and writable files? For seekable files? For text files? Etc.
Object --> Collection --> Sequence --> List \ \ \--> Tuple \ \ \--> String
Is a string really a collection?
\ \--> Set \ \--> Mapping --> Dict
How about readonly mappings? Should every mapping support keys()? values()? items()? iterkeys(), itervalues(), iteritems()?
\--> FileLike --> File \--> StringIO \--> Number --> Complex \--> Real --> Integer --> Long
Where does short int go?
\--> Float \--> Iterator \--> Iterable
etc.
The hierarchy could be further complicated with mutability (MutableSequence (e.g. list), ImmutableSequence (e.g. tuple, string)), or perhaps mutability could be a property of classes or even objects (allowing runtime marking of objects read-only? by contract? enforced?).
Exactly. Endless debate will be yours. :-)
This seems to be a library (not language) solution to the problem posed. Can the low level types implemented completely in C still descend from a python parent class without any performance hit?
Not easily, no, but it would be possible to put most of the abstract hierarchy in C.
Can someone please point out the inferiority or infeasibility of this method? Or is it just "ugly"?
Agreeing on an ontology seems the hardest part to me. --Guido van Rossum (home page: http://www.python.org/~guido/)