> Yes. There is a difference between the interface of an object (namely, > what methods and attributes it has and what their semantic meaning is) > and the class of an object (what methods and attributes it has and how > they are implemented.) > > In general, you shouldn't be asking about an object's class. Down the > road, you may want to use an object that isn't of the same class but > does support the interface. > > Consider how the file object is used in Python. Pretty much every > place you can use a file object you can use a StringIO, right? That's > because StringIO supports the file interface while it isn't a file. > > You may want to read up on 'duck typing' to get a better sense of why > this is important.
I have read also your next message and these are good arguments for dynamically typed languages and really convinces me - I mean that they provide some flexibility at the cost of writing a little more. They provide flexibility though in a different field. Duck typing is great, because it allows completely use of a completely different hierarchy, which only has to have the same interface. But I am looking for a different type of flexibility. I would like to be able to add more classes to my hierarchy and not have to change my code in many places when I add new class to the hierarchy. If I have to change every class in the hierarchy because I add new class, then it's not something I would like to do. And idea how I can avoid this? -- Filip Gruszczyński -- http://mail.python.org/mailman/listinfo/python-list
