PEP: Specialization Syntax

[Nicolas Fleury]

Hi everyone, I would to know what do you think of this PEP.  Any comment 
welcomed (even about English mistakes).

PEP: 	XXX
Title: 	Specialization Syntax
Version: 	$Revision: 1.10 $
Last-Modified: 	$Date: 2003/09/22 04:51:49 $
Author: 	Nicolas Fleury <nidoizo at gmail.com>
Status: 	Draft
Type: 	Standards Track
Content-Type: 	text/plain
Created: 	24-Jul-2005
Python-Version:	2.5
Post-History: 	
Abstract

     This PEP proposes a syntax in Python to do what is called in
     this document "specialization".  It contains more than one
     proposal:
     - Extend square brackets syntax to allow a full call syntax,
       using a __specialize__ method, similarly to the __call__
       method.
     - Extend function definition syntax to allow specialization
       of functions.
     - Parameterized types.


Motivation

     In his controversial blog entry "Adding Optional Typing to
     Python -- Part II" [1], Guido Van Rossum introduced the idea
     of "parameterized types" in Python.  The proposition was to
     use [square brackets] rather than <pointy ones> to allow
     prototyping with __getitem__ method.  However, the __getitem__
     method is not flexible enough.  It doesn't support keyword
     arguments and using multiple and default arguments can be pain,
     since the only argument received would be a tuple.  Calling
     can also be error-prone if a tuple can be allowed as a first
     argument.  This PEP proposes to enhance square brackets syntax
     to allow full-call syntax as with parenthesis.

     Note that Guido dropped the idea, for now, of parameterized
     types in a following blog entry [2].  This PEP introduces
     parameterized types only as a last step, and focus more on
     having a syntax to prototype them.  This PEP can also serve
     as a place to discuss to feature of specialization independently.

     The term "specialization" is used in that document because
     "parameterized functions" would sound like an already available
     feature.  As Guido pointed out [1], "generic" is neither a good
     term.  Specialization is a term in that case borrowed from C++.
     The term alone is not perfect, since it refers to the action of
     passing arguments to a "parameterized type" (or function) to
     make it usable and a term must still be found to describe the
     "unspecialized" type or function.

     Another motivation to this PEP is the frequent usage in Python
     of functions to create functions.  This pattern is often used
     to create callback functions and decorators, to only name these.
     However, the fact that both the creation and the use is using
     parenthesis can be confusing.  Also, a programmer ends up naming
     two functions, when only the creating one is called by name and
     the created one is doing the job.  Some programmers ends up
     naming the creating function with the name they would want to
     give to the created function, confusing even more the code using
     it.  To fix this situation, this PEP proposes a syntax for
     function specialization.


__specialize__ Special Member Function.

     The first element of this proposal is the addition of the
     __specialize__ special member function.  The __specialize__
     function can have the same signatures as __call__.  When
     defined, the definition of __getitem__ has no effect, and
     __specialize__ will be called instead.

     The language grammar is extended to allow keyword arguments
     and no arguments.  For example:

         class MyObject(object):
             def __specialize__(self, a=4, b=6, *args, **kwargs):
                 pass

         obj = MyObject()
         obj[b=7, a=8, c=10]
         obj[]

     Note that when __specialize__ is defined, __setitem__,
     __getslice__ and __setslice__ are still used as before.


The specializer Decorator

     To explain the syntaxes proposed in this PEP, the following
     decorator is used:

         class Specializer:
             def __init__(self, callableObj):
                 self.callableObj
                 self.__name__ = callableObj.__name__
             def __specialize__(self, *args, **kwargs):
                 self.callableObj(*args, **kwargs)

         def specializer(callableObj):
             return Specializer(callableObj)

     It takes a callable and make it callable with square brackets
     instead.


Function Specialization

     A common pattern in Python is to use a function to create
     another function:

         def makeGetMemberFunc(memberName):
             def getMember(object):
                 return getattr(object, memberName)
             return getMember

         foo(makeGetMemberFunc('xyz'))

     The second element of this proposal is to add a syntax so
     that the previous example can be replaced by:

         def getMember[memberName](object):
             return getattr(object, memberName)

         foo(getMember['xyz'])

     which is equivalent to:

         @specializer
         def getMember(memberName):
             def getMember(object):
                 return getattr(object, memberName)
             return getMember

         foo(getMember['xyz'])


Class Specialization

     The last element of this proposal is to add a syntax to pass
     arguments to class creation:

         class List[ElementType=object](list):
             ...

     This would be the equivalent to:

         @specializer
         def List(ElementType=object):
             class List(list):
                 ...
             return List

     Note that the additional syntax is inserted before the
     inheritance, different than what was initially proposed [1].
     The reason is that inheritance can need the specialization
     arguments, and it is more intuitive to use an argument
     after its introduction:

         class MyList[ElementType=object](List[ElementType]):
             ...


Backward Compatibility

     The three propositions are backward compatible.


Open Issues

     Instead of adding a __specialize__ method, the __getitem__
     method could be changed to allow additional signatures:

         def __getitem__(self, *args, **kwargs): ...

     Should other operators that square brackets be used for
     specialization?


References

     [1] Adding Optional Static Typing to Python -- Part II,
         Guido van Rossum
         http://www.artima.com/weblogs/viewpost.jsp?thread=86641

     [2] Optional Static Typing -- Stop the Flames!, Guido van Rossum
         http://www.artima.com/weblogs/viewpost.jsp?thread=87182


Copyright

     This document has been placed in the public domain.