Bengt Richter wrote: > I don't understand why you wouldn't give the function arg a different name > in the first place instead of via a temporary intermediary binding, e.g., > > def makeType(someArgument_alias): > class MyObject: > someArgument = someArgument_alias > return MyObject
Because that would affect documentation and keyword arguments. Both the constructed class *and* the function are exposed to the user, so it needs to be coherent. >>__arrayTypes = {} >>def makeArrayType(arg1, arg2=someDefault): >> if (arg1, arg2) in __arrayTypes: >> return __arrayTypes[arg1, arg2] >> renamed_arg1 = arg1 >> renamed_arg2 = arg2 >> class Array: >> arg1 = renamed_arg1 >> arg2 = renamed_arg2 >> ... >> __arrayTypes[arg1, arg2] = Array >> return Array >> > > Or (untested, using new style class): > > def makeArrayType(arg1, arg2=someDefault): > try: return __arrayTypes[arg1, arg2] > except KeyError: > __arrayTypes[arg1, arg2] = Array = type('Array',(),{'arg1':arg1, > 'arg2':arg2}) > return Array > > (just re-spelling functionality, not understanding what your real use case is > ;-) Well, of course, but I didn't wrote the rest of the class definition;) So I need a place to put the class definition. In the end, it looks very much like the mess in the example. Maybe I'm missing a solution using decorators. I've defined a few classes like that, and I can live with it, but having a syntax to do it more easily, I would use it right away. I guess it can also be useful for people interfacing with COM or typed contexts. Regards, Nicolas -- http://mail.python.org/mailman/listinfo/python-list