Reply to thread

Message

[QUOTE="Nicolas Fleury, post: 1832231"]
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.

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
[/QUOTE]

Verification