[Python-Dev] Adding types.build_class for 3.3 (original) (raw)
Mark Shannon mark at hotpy.org
Thu May 10 10:11:02 CEST 2012
- Previous message: [Python-Dev] Adding types.build_class for 3.3
- Next message: [Python-Dev] Adding types.build_class for 3.3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 buildclass().
+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.
- Previous message: [Python-Dev] Adding types.build_class for 3.3
- Next message: [Python-Dev] Adding types.build_class for 3.3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]