Feature/expose rate limit headers

[abelsm2]

This PR exposes the rate limit response headers so end users can plan a strategy to try to avoid being rate limited. It adds a class property that is updated on each call to the /data API, along with several getter methods to retrieve the information. There are no changes to any of the existing public methods and this should be completely backwards compatible.

Closes #54.

[jasondilworth56]

This is great, and I thank you for the effort. That said, I think this is a great opportunity for us to work towards something more type safe and class based.

I'd suggest putting most of the rate limit stuff into it's own class, say irRateLimit which could have implementations like this:

• update() does similar to your current _store_rate_limit_headers
• @property methods for what you currently have in get_rate_limit_limit etc

That could all then mean that those lose the Optional aspect, because the Optional would be on the existance of an irRateLimit on the main client.

class irDataClient:
  rate_limit: Optional[irRateLimit] = None

  def _update_rate_limit(self, r: Request):
    self.rate_limit = self.rate_limit.update(r) if self.rate_limit else irRateLimit(r)

Then anyone using the client can do something like ird.rate_limit.remaining or ird.rate_limit.reset_time and work accordingly. What do you think?

[abelsm2]

I'll take a shot at it. BTW, what version of python does this project use?

[jasondilworth56]

Good luck, let me know if you have any issues on the way - I'm jasondilworth on Discord if you want to bounce stuff around.

Python version wise I use it in projects 3.10-3.12 at the moment but that's yet another thing I'd like to do at some point - get a Tox setup here to test lots of environments automatically.

[abelsm2]

setup.py shows 3.6, but since 3.9 is about to go end-of-life, I will make the new class compatible with 3.10+. My personal project is on 3.12 (which is where I started using Python), so if you catch anything not compatible just let me know.

[abelsm2]

I moved everything into a class. The single tests.py was getting very large, so in the interest of organization, I also moved the class tests into their own test module and moved all the tests into a /tests folder. I hope that was ok.

[jasondilworth56]

That's looking real good – I almost pointed out a couple of picky things but this isn't work!

We're very much on the same page tests wise, I've got a draft PR for doing more wide ranging type safety that does very similar: #57, I'll sort that based on your changes at some point.