Can't Use 'method' As Query Param about restkit HOT 11 CLOSED

Proposal...rewrite Resource.request() as:
def request_dict(self, method, path=None, payload=None, headers=None, params=None):

And have it called from:
def request(self, method, path=None, payload=None, headers=None, **params):

Easy enough fix to implement while preserving existing compatibility.

from restkit.

i'm not sure to follow, method isn't a named argument, so it should works, anyway rather than implementing another function maybe just doing def request(self, method, path=None, payload=None, headers=None, **params) where paramas is a dict in your code is enough ?

from restkit.

'method' is a named argument to Resource.request(). See line 181 of restkit/resource.py:

def request(self, method, path=None, payload=None, headers=None,
    **params):
    """ HTTP request

    This method may be the only one you want to override when
    subclassing `restkit.rest.Resource`.

    :param payload: string or File object passed to the body of the request
    :param path: string  additionnal path to the uri
    :param headers: dict, optionnal headers that will
        be added to HTTP request.
    :param params: Optionnal parameterss added to the request
    """

If you're confused because you see '_method' in the error above it's because I attempted to rename it in my overloaded method, but that doesn't matter because my overloaded method still has to call Resource.request() with the same params dict which contains a 'method' key and so it errors out.

I am passing the params argument as a dict when that error is generated, it makes no difference how you pass the arguments it still errors out.

from restkit.

well method is an argument not a key argument that what I meant. I reproduce the issue _method isn't really friendly though, so looking for another way.

from restkit.

I agree, it's not a clean fix. My second option isn't a very clean fix, either, though I think it works better. Ideally there would be a third option that won't break existing applications built on top of restkit but I don't see one.

from restkit.

I'll be honest, my main concern is making any changes that would break couchdbkit. I just realized you're also the developer behind that project as well, so I suppose that is not really an issue as you can make changes to couchdbkit to support any changes made in restkit.

from restkit.

Well, the main issue here is to keep the compatibility with existing code. There is a new resource thing coming with 2.3 this weekend that should allows that.

from restkit.

There's no such thing as 'key arguments', if I understand what you mean. Python will attempt to use any keyword arg on whatever matching param it can find (and then the leftovers go to **kw, if the function is taking kwargs).

I agree this is an important problem, but I think we can make a solution that doesn't require an alternate 'request_dict' method:

def request(self, method, path=None, payload=None, headers=None, 
            params={}, **kwParams):
    kwParams.update(params)
    ...

Now kwParams is catching all the old-style params (except I have reserved the name 'params', so that's a very minor incompatibility), but we can pass params as a dict in a very natural way. The caller can even combine both approaches:

s.request("GET", "/foo", params={'headers':'hello'}, message='world')
-> GET /foo?headers=hello&message=world

from restkit.

key argumenst are are kwargs in my mind :) Like your idea anyway, that could indeed works.

from restkit.

and fixed. thanks for the trick :)

from restkit.

https://github.com/benoitc/restkit/blob/master/restkit/resource.py#L185 still has a problem: it expects to be able to pass the user's arbitrary params_dict as keyword args to make_uri, which breaks with params_dict={"base":"hi"}, for example. make_uri ought to take a dict instead of kwargs.

from restkit.