Add the cache expiration time to APIObjects.

[Acidity]

This allows consumers of the library to access the cache expiration time so they can use it as necessary.

[Acidity]

Looks like this should solve issue #7.

[jonobrien]

usable?

[wtfrank]

I see that you've decided to augment the return value so that its now a tuple containing the original data + the expiry time.

I looked at how evelink (xml api library) deals with returning expiry time, and it returns the timestamp (i.e. the time the item was created) as well as the expiry time.

The second thing that evelink does is it returns a collections.namedtuple rather than tuple. This means that you can do something like X.contracts().result, X.contracts().expires, or X.contracts().timestamp which is quite readable.

That said, doing result, timestamp, expires = X.contracts() as you would with a tuple is still quite readable. Though in the simple case where you don't care about the cache info, you would do result, _, _ = X.contracts() but then that's not so readable.

One problem with using both tuple and namedtuple is that they break existing code. I wonder if there's a way that we can have our cake and eat it, by retaining compatibility with existing code, without making it ugly. Maybe not possible though!

[hkraal]

Would it really be so hard to keep thing from breaking? I mean X.contracts().result will go through the APIObject.getattr() while X.contracts() goes through APIObject.call() which just as easily could return self().result?

Before we do that we really should get some deprecated notices going for these kind of things