driver_stats doesn't appear to parse the response correctly

[dfaulken]

I receive the error TypeError: list indices must be integers or slices, not str here:

pyracing/pyracing/client.py

Lines 290 to 291 in 3cea16a

	return [historical_data.DriverStats(x) for
	x in response.json()["d"]["r"]]

Haven't examined the response personally, but wondering if this is because multiple driver records are returned.

[Esterni]

Hmm, not sure on this. That could be the case, otherwise it could be that iRacing changed the structure of data returned

[dfaulken]

OK, found it. The issue is because with the specific query that I was running (trying to use search to find a cust ID from a name), response.json()['d'] was an empty array.

[dfaulken]

DriverStats seems to return nothing if I try to use the search parameter. I'm having better luck with GetDriverStatus's searchTerms parameter. For instance the response from https://members.iracing.com/membersite/member/GetDriverStatus?searchTerms=David+McCourt is:

{"blacklisted":false,"search":1,"studied":false,"fsRacers":[],"friends":false,"searchRacers":[{"broadcast":{},"hidden":true,"helmet":{"c3":"000000","ll":20,"hp":40,"ht":0,"c1":"000000","ft":0,"c2":"802020"},"custid":498405,"name":"David+McCourt","trustedAsSpotter":false}]}

which does include my cust_id 498405.

So perhaps rather than recommending using DriverStats for getting a customer ID from a name, GetDriverStatus should be extended to allow client user to specify searchTerms?

[XanderRiga]

For what it's worth, the tests are failing on this as well, so I am guessing iRacing changed the way they structure their data. Feel free to put up a PR to fix those methods.

[dfaulken]

Thanks @XanderRiga. Does it seem appropriate to add functionality to get_driver_status to allow finding cust_id that way?

[XanderRiga]

So the point of pyracing was to try not to be too opinionated about how people might use the endpoints. We do have an endpoint for the driver status here, which returns a DriverStatus object which contains a cust_id field on it, so that is totally a valid way to access the cust id. I wouldn't create a new method for it as that is dipping into territory of us telling you how to use the endpoints, these are just some endpoints that we wrap as appropriately as we can.

[XanderRiga]

Oh, hang on. I didn't understand the question quite well enough. Yes that endpoint only allows queries via cust_id. If you wanted to build a proper query interface for that so it isn't hard-coded that way, then yes that would be an awesome addition