PEP: Specialization Syntax

[Nicolas Fleury]

Bengt Richter wrote:
>>__specialize__ Special Member Function.
> 
> By "Member Function" do you mean anything different from "method"?

No, I should have written method.  C++ habit.

>>    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
> 
> Any function can have any legal signature, so I'm not sure what you are saying.

You're right, I should focus on the syntax change, to call __getitem__ 
(or __specialize__) automatically.

>>    defined, the definition of __getitem__ has no effect, and
>>    __specialize__ will be called instead.
> 
> What about subclassing and overriding __getitem__ ?

I have no problem with that.  I even suggest it at the end of the PEP.

But don't you think the name "__getitem__" is not appropriate then?

> here you can currently write
>               __getitem__ = __specialize__
> although you have to remember that obj[:] and related slicing expressions
> become legal and that obj[] does not, without a language sysntax change.

Yes, the PEP is about that syntax change.

>>        class Specializer:
>>            def __init__(self, callableObj):
>>                self.callableObj
> 
>                                    ^^?? = callableObj ?

Yes, "= callableObj" is missing.

>>    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'))
> 
> 
> Either closures like the above or bound methods work for this,
> so you just want more concise spelling?

In the case of functions, yes.  For functions, I guess the syntax is 
much more useful is static typing is added, or planned to be added, in 
the language.  However, there's still use cases where it is useful.

> Have you looked at currying? E.g.,
>     http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52549

And partial will be in Python 2.5 (PEP 309).  Yes, I've look at it, but 
in my use cases the created function correspond to a specific function 
signature, so, for example, you always only want to specify the 
"memberName" argument.  Currying is nice, but since any argument can 
supplied, the code is less self-documenting.  But I used these in 
day-to-day programming.

>>        class MyList[ElementType=object](List[ElementType]):
>>            ...
> 
> Before I'd want to extend class syntax this way, I think I'd want to
> explore some other aspects of class syntax as well, with more (and
> more persuasive) use cases in view. Also more thought to what is done
> when and whether the issue is to supply information into existing control
> contexts or to modify control flow as well, to extend possibilities for
> customized processing.

What do you think of the example I post in a reply to Martin v.Lowis?

>>    Instead of adding a __specialize__ method, the __getitem__
> 
> When you say "the" __getitem__ method, what do you mean? AFAIK the
> method itself is an unrestricted function. It just happens that
> binding it as a class attribute __getitem__ makes it get called
> from code with square bracket access spellings. I think that's where
> your changes to allow "additional signatures" would have to go. I.e.,
> in generation of code from the "calling" syntax. To illustrate:
> 
>  >>> class C(object):
>  ...     def __getitem__(self, *args, **kwargs):
>  ...         return self, args, kwargs
>  ...
>  >>> c=C()
>  >>> c[1]
>  (<__main__.C object at 0x02EF498C>, (1,), {})
>  >>> c[1,2]
>  (<__main__.C object at 0x02EF498C>, ((1, 2),), {})
>  >>> c[:]
>  (<__main__.C object at 0x02EF498C>, (slice(None, None, None),), {})
>  >>> c[kw='key word arg']
>    File "<stdin>", line 1
>      c[kw='key word arg']
>          ^
>  SyntaxError: invalid syntax
> 
> But here the problem is not in the __getitem__ method:
> 
>  >>> c.__getitem__(kw='key word arg')
>  (<__main__.C object at 0x02EF498C>, (), {'kw': 'key word arg'})
> 
> It's just that square bracket expression trailer syntax does not
> allow the same arg list syntax as parenthesis calling trailer syntax.

I totally agree and that's what I mean.  The formulation of the PEP is 
wrong, I should almost not talk about __getitem__ since as you said it 
can have any signature.  The PEP is about extending [] syntax to call 
automtically __getitem__ function with more complex signatures.

>>    Should other operators that square brackets be used for
>>    specialization?
> 
> Didn't quite parse that ;-) You mean list comprehensions? Or ??

I mean should angle brackets <> like in C++, or another operator, be 
used instead?

Regards and thx for your feedback,
Nicolas