python improvements (Was: Re: New Language)

Bernhard Herzog 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:
> [snip]
> > - 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[1]
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.


[1] 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 mailing list