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