Self parameter is None in mutate method

I don’t know, maybe it’s not a bug and problem caused by rx, but i have this mutation

class ExtendedMutation(graphene.Mutation):

    ok = graphene.Boolean()
    code = graphene.Int()
    message = graphene.String()

    def mutate(self, *_, **__):
        return ExtendedMutation()

class UserLogin(ExtendedMutation):
    class Arguments:
        access_token = graphene.String()

    access_token = graphene.String()

    @login_required
    def mutate(self, info, access_token):
        response = client.login(access_token)
        access_token = response.get('data', dict()).get('access_token', None)

        return UserLogin(
            access_token=access_token,
            ok=response.get('ok'),
            code=response.get('code'),
            message=response.get('message')
        )

and wrote such decorator

def login_required(mutation):
    @wraps(mutation)
    def inner(obj, info, **kwargs):
        access_token = request.headers.get('access_token', None)

        print('obj: {}, info; {}, kwargs: {} '.format(obj, info, kwargs))
        if not access_token:
            return obj(
                ok=False, code=401, message='You must login first'
            )
        return mutation(obj, info, **kwargs)
    return inner

I wait for UserLogin object in self argument of mutation method, but it’s equal None. Info is equal ResolveObject. When i wraps mutate method with @classmethod decorator, i got UserLogin login class, info is None and appears third position required argument which is actually is info.

Any ideas?

[henryfjordan]

The intended behavior here makes no sense. The point of a library like graphene is fit some abstraction like graphql into the domain of python. When you ignore the conventions of the target domain (namely python’s use of self on methods in classes), you have failed to make a good library.

If I wanted the function signatures to be exactly the same as Apollo, I’d use Apollo.

Please reinstate self on resolve_... methods and Mutation classes

[vladcalin]

I also experience some frustrations with this and I think this is intended. I remember I saw a discussion in another issue related on this and the conclusion was that this design was deliberately implemented like this but I don’t remember the justification and I can’t seem to find the issue right now.

I think this is a very poor design choice as it doesn’t allow any OOP principle to be applied for mutations and queries as I can’t access any method or member. What’s the point of using classes if you can’t use OOP principles anyway?