Bug: object function variable will pass self in to the function

[hichuang]

I'm writing generator class, and found an issue of the object member variable suppose we have a class define as follow:

class A:
    def __init__(self, f):
        self.f = f
    def __next__(self):
        return self.f()

When I initialize an instance a say

def func():
    print('test')

a = A(func)
a.__next__()

we will have an Arity Mismatch Error, because our implementation when calling self.f() will pass self to f() as well, which func did not take any argument

[amtriathlon]

I am having a similar problem with multiple inheritance tests, when a method is called as cls.method(obj) instead of obj.method() it gives arity mismatch, for example:

print("xxx".str())

works, but

str.str("xxx")

gives arity mismatch.

[mpmilano]

Yes - I noticed the same earlier. Not sure who to talk to about this.

On Monday, January 7, 2013, Alejandro Martinez wrote:

I am having a similar problem with multiple inheritance tests, when a method is called as cls.method(obj) instead of obj.method() it gives arity mismatch, for example:

print("xxx".str())

works, but

str.str("xxx")

gives arity mismatch.

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/23#issuecomment-11980120.

[amtriathlon]

The problem, in both cases, is the lack of a method object, which should be constructed on attribute retrieval to distinguish bound/unbound calls (https://github.com/brownplt/lambda-py/issues/13), I planned to add this after multiple inheritance extensions, but according to an email of Matthew Milano on googlegroups the scope group is working on lookup order, so I think we should wait to have the new scope merged before.

[mpmilano]

Shoot - clarification. We aren't actually working on lookup order, we are just assuming that that is roughly how look up order should work.

On Tuesday, January 8, 2013, Alejandro Martinez wrote:

The problem, in both cases, is the lack of a method object, which should be constructed on attribute retrieval to distinguish bound/unbound calls (

13 https://github.com/brownplt/lambda-py/issues/13), I planned to add

this after multiple inheritance extensions, but according to an email of Matthew Milano on googlegroups the scope group is working on lookup order, so I think we should wait to have the new scope merged before.

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/23#issuecomment-11996113.

[amtriathlon]

Fixed in multiple_inheritance branch https://github.com/brownplt/lambda-py/commit/fa69d52067f32797720a22da37da4b25d8616be2