Nick Coghlan wrote: > On Thu, May 10, 2012 at 10:03 AM, Greg Ewing > <greg.ewing at canterbury.ac.nz> wrote: >> Python is not Java -- we have modules. 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(). +1 > > Not true - you *will* get a type instance out of any sane call to > type.define(). Technically, you could probably declare your metaclass > such that you get a non-type object instead (just as you can with a > class definition), but that means you're really just using an insanely > convoluted way to make an ordinary function call. If you didn't want > to invoke the full PEP 3115 find metaclass/prepare namespace/execute > body/call metaclass dance, why would you be calling type.define > instead of just calling the metaclass directly? By attaching the 'define' object to type, then the descriptor protocol causes problems if 'define' is a desriptor since type is its own metaclass. If it were a builtin-function, then there would be no problem. A module-level builtin-function is more likely to be correct and seems to me to be more Pythonic. Not that I'm a good judge of Pythonicness :) Finally, could you remind me how the proposed type.define differs from builtins.__build_class__? I can't see any difference (apart from parameter ordering and the extra name parameter in builtins.__build_class__). Cheers, Mark.
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