Nick Coghlan wrote: > On Thu, May 10, 2012 at 10:03 AM, Greg Ewing > <greg.ewing at canterbury.ac.nz> wrote: > >>Something should >>only go in a class namespace if it somehow relates to >>that particular class, and other classes could might >>implement it differently. That's not the case with >>build_class(). > > Not true - you *will* get a type instance out of any sane call to > type.define(). You must have misunderstood me, because this doesn't relate to the point I was making at all. What I'm trying to say is that I don't see the justification for making build_class() a static method rather than a plain module-level function. To my way of thinking, static methods are very rarely justified in Python. The only argument so far in this case seems to be "we can't make up our minds where else to put it", which is rather lame. A stronger argument would be if there were cases where you wanted to define a subclass of type that implemented build_class differently. But how would it get called, if everyone who uses build_class invokes it using 'type.build_class()'? -- Greg
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4