> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4