On Sun, 07 Aug 2005 17:20:25 -0400, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
>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:
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
>
>__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
;-)
>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.
I agree with this, until I see some really persuasive use cases.
>
>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.
>
I'll have to catch up with that. Have been very bogged down for a long while.
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
