Feature Request: Create an abstraction layer for a single Account
Proposal is to create a class that handles all actions for a single account. This would be a successor to passing account_hash to various client methods.
Current pattern:
linked_accounts = client.account_linked().json()
account_hash = linked_accounts[0].get('hashValue') # this will get the first linked account
print(client.account_details(account_hash, fields="positions").json())
print(client.account_orders(account_hash, datetime.datetime.now(datetime.timezone.utc) - datetime.timedelta(days=30), datetime.datetime.now(datetime.timezone.utc)).json())
Proposed pattern:
linked_accounts = client.account_linked()
acct = linked_accounts.get_account_by_id("12345678")
account_hash = acct.get_hash_value() # You wouldn't really need this. But it's available
print(acct.get_details(fields="positions").json())
print(acct.get_orders(start_offset_days=30, end_offset_days=0).json())
Caveats:
Account class would need the connection information of the client, or an actual copy of the client. This means that any mutations to client may or may not be reflected in an instantiated Account, which (in either direction) could be confusing to the user.
One option would be to create a subclass then override all api function signatures. Keep in mind that the account hash changes with every refresh token (or maybe access token?) so there would need to be something in the token updater too. I like the idea of this but maybe instantiation could go like this:
acct = schwabdev.Account('12345678')
# then make calls from acct...
What do you think? Also, sorry for my late response.
Great point! Didn't know the hash change.
Subclass seems unintuitive to me. Do you mean that Account class will actually be a Client class?
In a way, yes. An account class would have the same functions as the client class unless we override them and additional functions could be added without modifying the client superclass. I will look into this idea in the future.