"Thomas Heller" <thomas.heller@ion-tof.com> wrote in message news:mailman.987779255.16686.python-list@python.org...
There are some signs :-) that Python's object model is going to be revised even _before_ Python 3000.
Is someone willing to join me fighting for class methods (I mean 'real' class-methods in the Smalltalk style here, _not_ static methods like in Java or C++).
I posted this in another thread, but I think it bears repeating here. I consider classes/instances a special case of namespaces: one which allows (multiple) instantiation and inheritance. In actual pratice not all of the classes I design are designed for multiple instantiation, or instantiation at all for that matter. What I would like to see is a separation of concerns ("Does this namespace have __special__ attributes for operator overloading?" inpdependent from "Does this namespace require instantiation?") followed by a culling of irrelevant features ("Don't want operator overloading? Don't name your function '__add__' then."). The resulting programming language might look something like this: namespace A: # Create a named unique object pass namespace B(A): # Similar to 'from ... import', but done through linking # instead of copying class C(A): # 'class' = namespace that requires/supports instantiation # class inherits from namespace => functions in namespace # are treated as "static" functions pass namespace D(C()): # namespace inherits from instance of class pass The module itself would be a 'namespace' object. Overall, I think this has the potential of creating a much simpler and more regular language. Separate keywords for 'class' and 'namespace' might even turn out to be unnecessary. In this context, class methods would either be automatically included, or turn out to be truly redundant, or both. -- Rainer Deyke (root@rainerdeyke.com) Shareware computer games - http://rainerdeyke.com "In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor