python improvements (Was: Re: New Language)
herzog at online.de
Tue May 16 00:36:05 CEST 2000
m.faassen at vet.uu.nl (Martijn Faassen) writes:
> Russell E. Owen <owen at astronojnk.washington.edu.invalid> wrote:
> > - class methods (e.g. ClassName.doSomething(...)). Often useful where
> > global functions might otherwise be wanted. By requiring the class name
> > one gets namespace protection and categorizes the function as relevant
> > to objects of the given class.
> Hm, how would this provide you with more namespace protection than the
> current module system? By being in the same module, a function also
> gets categorized as relevant to objects of the classes defined in the
> module, too..
I used to think this too, but recently I actually had a situation where
class methods would have been useful. I had a list of classes, so the
classes were effectively anonymous and I didn't know where each class
came from, yet I wanted to get some class specific information that I
wanted to compute at that time and not at class creation time (when the
class statement is executed).
I couldn't just instantiate the classes to get at real methods because
the constructors required some arguments I couldn't supply at that time
and while it's possible to get at the module the class was defined in
but I didn't want to rely on that.
In that situation, real class methods would have been useful and cleaner
than any other solution. In the end, I fell back to normal class
attributes that are computed at class definition time because it works
well enough for the time being.
 e.g. sys.modules[classobj.__module__] to get the module or
classobj.method.im_func.func_globals to get the globals dict
Bernhard Herzog | Sketch, a drawing program for Unix
herzog at online.de | http://sketch.sourceforge.net/
More information about the Python-list