Quote Originally Posted by gordonb3 View Post
Not too big on python myself and I also hate the fact that running watchforstock's library takes 40-50 seconds to load and execute on the embedded system I use. But as far as I can see python does not appear to have a mechanism for privatizing variables, so you should be able to dump the API key to screen using `print client.access_token` (and its expiration time `client.access_token_expires`).

The only real problem here is that the client init procedure automatically calls the _login method. You need to delete that line in the library and then let your script decide whether to inject the API key from local storage or run the usual login procedure.
Quote Originally Posted by gordonb3 View Post
Previous entry should apply to both APIs. In both cases the library requires you to supply your credentials on creation of the client object and neither one needs a separate call to the login procedure. Both login procedures return a token that must be sent with every subsequent call and is thus stored within the client object, so between runs you can save and restore that token rather than request a new one by logging in again.
Printing client.access_token and client.access_token_expiry in my simplified test script does indeed work, so you've given me an idea.

Instead of modifying the library I may be able to duplicate some of the client init procedure in my own script minus calling _login as a workaround. Effectively I'd be adding my own library function to do a cached login but just within my own script, and keeping track of the token and expiry manually in my own script.

I'm not sure of the intricacies of how python libraries work when they are imported (I just know how to import them and call their methods) and how feasible that is but I'll have a look into it.

At least until the library itself supports caching of the token across script instances (if it ever does) it might be a usable workaround.