PEP: Specialization Syntax

[Bengt Richter]

On Sun, 07 Aug 2005 17:20:25 -0400, Nicolas Fleury <nidoizo at yahoo.com> 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