Heiko Wundram wrote: > Matthias Kaeppler wrote: > > <snip a whole lot of talk of someone still thinking in terms of C>
Well, unless you are (or he is) in with the GNOME crowd, C probably isn't really the object-oriented language acting as inspiration here. [Zen of Python] Of course the ZoP (Zen of Python) is deep guidance for those languishing in some design dilemma or other, but not exactly helpful, concrete advice in this context. (I'm also getting pretty jaded with the recent trend of the ZoP being quoted almost once per thread on comp.lang.python, mostly as a substitute for any real justification of Python's design or any discussion of the motivations behind its design.) That said, the questioner does appear to be thinking of object-oriented programming from a statically-typed perspective, and I'd agree that, ZoP or otherwise, a change in perspective and a willingness to accept other, equally legitimate approaches to object-orientation will lead to a deeper understanding and appreciation of the Python language. Anyway, it appears that the questioner is confusing declarations with instantiation, amongst other things: > And how do I formulate polymorphism in Python? Example: > > class D1(Base): > def foo(self): > print "D1" > > class D2(Base): > def foo(self): > print "D2" > > obj = Base() # I want a base class reference which is polymorphic Well, here one actually gets a reference to a Base object. I know that in C++ or Java, you'd say, "I don't care exactly what kind of Base-like object I have right now, but I want to be able to hold a reference to one." But in Python, this statement is redundant: names/variables potentially refer to objects of any type; one doesn't need to declare what type of objects a name will refer to. > if (<need D1>): > obj = D1() > else: > obj = D2() Without the above "declaration", this will just work. If one needs an instance of D1, one will assign a new D1 object to obj; otherwise, one will assign a new D2 object to obj. Now, when one calls the foo method on obj, Python will just find whichever implementation of that method exists on obj and call it. In fact, when one does call the method, some time later in the program, the object held by obj doesn't even need to be instantiated from a related class: as long as the foo method exists, Python will attempt to invoke it, and this will even succeed if the arguments are compatible. All this is quite different to various other object-oriented languages because many of them use other mechanisms to find out whether such a method exists for any object referred to by the obj variable. With such languages, defining a base class with the foo method and defining subclasses with that method all helps the compiler to determine whether it is possible to find such a method on an object referred to by obj. Python bypasses most of that by doing a run-time check and actually looking at what methods are available just at the point in time a method is being called. > I could as well leave the whole inheritance stuff out and the program would > still work > (?). Correct. Rewinding... > Does inheritance in Python boil down to a mere code sharing? In Python, inheritance is arguably most useful for "code sharing", yes. That said, things like mix-in classes show that this isn't as uninteresting as one might think. Paul -- http://mail.python.org/mailman/listinfo/python-list
