gangesmaster wrote: > let's start with a question: > > ========== > >>>>class z(object): > > ... def __init__(self): > ... self.blah=5 > ... > >>>>class x(object): > > ... def __init__(self): > ... z.__init__(self) > ... > >>>>y=x() > > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "<stdin>", line 3, in __init__ > TypeError: unbound method __init__() must be called with z instance as > first argument (got x instance instead) > ========== > > and the question is -- WHY? > > what is a type? generally speaking, if everything were an object, the > type only defines the MRO (method resolution order) for that object. > x.y first looks at the instance, then the class, then the parent > classes, etc. (this was changed a little in python2.3 to something more > complicated, but it's basically the same). > > you can see the mro like this: > ========== > >>>>class x(object): pass >>>>class y(x): pass >>>>class z(y): pass >>>>a=z() >>>>print a.__class__.mro() > > [<class '__main__.z'>, <class '__main__.y'>, <class '__main__.x'>, > <type 'object'>] > ========== > > after all, if we stay out of builtin types, all python objects are > dicts, which support chian-lookup according to the mro. and a method is > just a function that takes the instance as a first argument. so why is > all this type hassle necessary? > > if we've taken it that far already, then let's really go over the edge. > I WANT TO DERIVE FROM INSTANCES. not only types. > > why? i'm the developer of rpyc (http://rpyc.sf.net), and i got a > request from someone to add support for deriving from remote types. the > concrete example he gave was quite silly, but after i thought about it > a little, i said why not try? > > a little intro about rpyc: it gives you proxies (instances) to remote > objects, which can be instances, functions, or classes. and that user > wanted to do something like this: > > class my_frame(conn.modules.wx.Frame): > ... > > so the client was actually creates the graphics on the server. not very > usable, but why not? all it means is, when he does "my_frame.xyz", > python should add the remote type to the mro chain. not too bizar. > > but __mro__ is a readonly attribute, and deriving from instances is > impossible (conn.modules.wx.Frame is a PROXY to the class)... > > and again -- WHY? these all look like INTENTIONAL limitations. someone > went around and added type checks (which are NOT pythonic) into the > cPython implementation. argh. why do that? > > so i thought -- let's be nasty. i created a function that creates a > class that wraps an instance. very ugly. small children and peope with > heart problems should close their eyes. > > ============ > def derive_from(obj): > class cls(object): > def __getattr(self, name): > return getattr(obj, name) > return cls > > class my_frame(derive_from(conn.modules.wx.Frame)): > .... > ============ > > the actual implementation is quite more complex, but that shows the > concept. > so now i'm experimenting with that little shit. but then i came to the > problem that methods check the type of the first argument... ARGH. dont > check types. DONT. the whole point of duck-typing is you DONT CHECK THE > TYPES. you just work with objects, and instead of TypeError you'd get > AttribiuteError, which is much better. AAARRRRRRGGGHH. > > python is EVIL at the low level. the high-level is just fine, but when > you try to go under the hood... you better go with an exorcist. > Take a look at languages like Self. Self was actually the first prototype-based OO language. You could consider Javascript to be a prototype-based language as well.
regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list