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