PEP: Specialization Syntax

[Nicolas Fleury]

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