Guido van Rossum wrote: > > [me] > > > - Class/type dichotomy??? > > [MAL] > > One thing that would probably be implementable is a way to > > maintain "instance" dictionaries for types (which are created > > on-demand whenever an assignment is made). > > > > This would enable > > extending types with new methods and attributes. "Subclassing" > > could then be emulated by using new contructors which add the > > new or changed methods to each created type instance, e.g. > > > > class myclose: > > > > def __init__(self, object, basemethod): > > self.object = object > > self.basemethod = basemethod > > > > def __call__(self): > > print 'Closed file %s' % self.object > > self.basemethod() > > > > def myfile(filename): > > f = open(filename) > > # add/override attributes > > f.newattribute = 1 > > # add/override methods > > f.close = myclose(f, f.close) > > return f > > > > Types would have to be made aware of this possibility. Python > > could provide some helping APIs to make life easier for the > > programmer. > > But this would require an extra pointer field for *all* built-in > types. That would seriously impact the space requirements for ints > and floats! True. > As long as we're proposing hacks like this that don't allow smooth > subclassing yet but let you get at least some of the desired effects, > I'd rather propose to introduce some kind of metaclass that will allow > you to use a class statement to define this. Thinking aloud: > > import types > filemetaclass = metaclass(types.FileType) > > class myfile(filemetaclass): > > def __init__(self, filename): > filemetaclass.__init__(filename) > self.newattribute = 1 > > def close(self): > myclose(self) > filemetaclass.close(self) > > I'm not quite sure what kind of object "filemetaclass" here should be > or what exactly "metaclass()" should do, but it could create a new > type that has the lay-out of an existing file object, with an instance > dictionary (for newattribute) tacked on the end. Later maybe (I'm > going to brainstorm with Jim Fulton about types and classes). I think the problem we currently have with subclassing types is strongly related to the fact that all Py<type>_Check() macros only work on a address compare basis. If we could find a way to change this to some kind of (very) fast different lookup scheme we'd open a door which could lead to making subclassing of types a whole lot easier. <Brainstorming> Perhaps a simple indirection could help... instead of obj->ob_type == PyInteger_Type we'd write obj->ob_type->base_type == PyInteger_Type_ID. A subclass could then identify itself as integer subclass by setting the base_type id to PyInteger_Type_ID. It would of course have to publish the same internal structure in order to remain compatible to the PyInteger_*() API, but there would be a possibility to extend the object struct and slots could also be replaced with new ones. </> -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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