In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > > That usage (self is second parameter to B.test) is bound > > to cause trouble in general, but in this case doesn't have > > any effect I can see. The function call "test" would be > > resolved from its first parameter, instance of A, and that > > function would return 1. One of us is missing something > > here, could be me. > > Probably my example wasn't clear, let's try another: > > class A: > def test(a, **kwargs): return 1 > class B: > def test(b, **kwargs): return 2 > test(a=A(), b=B()) > > "self" isn't a keyword, so nothing should forbid this code. What is the > interpreter to do if it stumbles across this "test" call? I mean, > named-argument lookup is a tricky thing even if you do know what > function you're calling. If this would depend on one of the parameters, > I think it would become completely unintelligible. (you can think of > more complex examples yourself)
Still see no problem. Of course, it goes without saying that Python 2.4 doesn't work this way, but given that it's theoretically possible for f(a) to be resolved similarly to a.f, then I really do not see what you're seeing here. The kwargs parameter appears irrelevant from where I'm sitting. > > That's exactly the problem, it doesn't read from left to right, > > because we swap back and forth between function(parameter and > > parameter.function notation. > > That's because they're doing two different things: object.method() does > an attribute lookup, while function(parameter) looks for the function > in the current scope. But current scope is actually a compound lookup - function scope, global scope etc. Generalize it to object scope, and then you can have a notation that expresses these things consistently - QED. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
