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
--
http://mail.python.org/mailman/listinfo/python-list
