I feel that Python may be headed for a rat-hole. Currently we are mixing the
procedural-based paradigm with the OO paradigm. To implement procedures,
such as len(), we add the __len__ method to user classes. I understand the
reasons for doing so (speed, complexity, space, attainable), but it seems
backwards. Even by not opening up the builtin objects, it seems more
intuitive to implement all functions as methods ('some_string'.len()), at
the expense of space (backwards compatibility would be a breeze). For user
objects, Python should provide a set of base classes to have a more common
framework to start from.
Steve's problem has been solved in Smalltalk, where the class hierarchy
spells out one aspect of the type() functionality ('isKindOf' method), and
generalization addresses the other aspect ('species' method). I'm not saying
that this is *the* solution, but it is certainly more intuitive.
Comments?
| I'm not sure that I digested and understood all of the previous |
discussion
| between Jaap and Guido about instance vs class attributes. From | looking
| at some of the 0.9.9 changes, it looks as if some of the | semantics may
| have been changed in the light of that discussion. I may be wrong.
Just to clarify the current behavior of Python (0.9.9) w.r.t. class vs.
instance variables and methods:
o You can use either instance variables or class variable.
When you use class variables, you can refer to them in
any subclass and the variables will be looked up by
searching the base classes (i.e.
instance.__class__.variable)
o Only instance and unbound methods are supported. Class
methods are impossible in the current implementation.
-Jaap-