PEP: Specialization Syntax

[Nicolas Fleury]

Martin v. Löwis wrote:
> -1. I don't see the point of this PEP. Apparently, you want to define
> parametrized types - but for what purpose? I.e. what are the specific
> use cases for the proposed syntax, and why do you need to change the
> language to support these use cases? I very much doubt that there are
> no acceptable alternatives for each case.

Well, I'm using the alternatives.  For example, where I work we have 
built a small framework to create binary data to be loaded-in-place by 
C++ code (it might be presented at next GDC (Game Developer 
Conference)).  It uses metaclasses and descriptors to allow things like:

class MyObject(LoadInPlaceObject):
     size = Member(Int32)
     data = Member(makeArrayType(makePtrType(MyObject2, nullable=True)))
     ...

I know, it's not really Python, but still, defining functions like 
makeArrayType and makePtrType is a pain.  It is necessary to maintain a 
dictionary of types (to avoid redundacy) and simple things like:

def makeType(someArgument):
     class MyObject:
         someArgument = someArgument
     return MyObject

are not allowed.  So its ends up with something like:

__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

Does it qualify as an "acceptable alternative"? when it could have been:

class Array[arg1, arg2=someDefault]:
     ...

I probably should have put this example in the PEP.

> IOW, whatever it is that you could do with this PEP, it seems you could
> do this today easily.

The PEP validity is also very much influenced if optional static typing 
is planned to be added to the language.  I realize defending this PEP is 
much harder without static typing and my use cases imply typing of some 
sort anyway.

Regards,
Nicolas