[Python-Dev] type categories

[Guido van Rossum]

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