doomb0t
commented
6 years ago Hey (I don't work for discogs but I am bored today),
Just taking a peak at your changes here, it looks like you are sort of on the right track, but if you take a look at the return values from the fetch method it only returns a status code and the content.
This is why the travis CI checks have failed. You are expecting a return value which does not exist. Additionally, as documented here the rate limit information is returned in the response's headers. So in order to access this information the fetch method will need to either return resp.headers, it may need to parse the headers and return the desired rate limit data or provide a default value in the case of default responses.
This is because the fetchers do not return the whole response object but rather, information from the response that is relevant to the request. A suggestion I might make (in addition to changing the fetcher to give us rate limit info) would be to add attributes to the client object which is updated by the _get method.
I am able to get tests passing by changing the rest of the fetchers accordingly, as well as default responses. Another option is to change the expected return values into a single, named tuple and then check for the presence of the rate limit, but i think it is better practice to ensure one is always returned.
*edited headers access inline since requests is used instead of urllib
vreon
This may be a fix for issue #82. I used the header parameter 'X-Discogs-Ratelimit-Remaining' that Discogs provided to get alerted when we finished the maximum requests and wait a bit before continue.