[Python-Dev] type categories
Guido van Rossum
guido@python.org
Fri, 23 Aug 2002 13:15:27 -0400
> 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/)