Feature request - get_last_price(tickers)

[satyan-g]

• Tiingo Python version: 0.13.0
• Python version: 3.8
• Operating System: OSX

Description

The most common use case is to get snapshot price of a portfolio of tickers. It would be nice to have a simple api that takes a number of tickers and returns the last price. It sure can be implemented using existing apis like get_dataframe, but that is going to be inefficient in many ways for following reasons.

1. You have to guess the correct start date. Creates a problem when 'now' is a holiday or weekend
2. You end up discarding all the data except the last row for each ticker - reduces network traffic
3. We most likely only need the adjClose and possibly the time/date of that price - reduces network traffic

What I Did

[hydrosquall]

This is a good idea regarding saving network traffic! Currently there isn't a way as the user to specify what fields should be returned (like with a GraphQL server), so many fields do end up going unused, perhaps @tiingo may have a take on whether there are any plans to implemented this.

Currently, if both startDate and endDate are omitted from the end-of-day endpoint, you will get the latest price

 response = client.get_ticker_price("GOOG")
# response printed out
[{'adjClose': 1731.01,
  'adjHigh': 1755.11,
  'adjLow': 1720.22,
  'adjOpen': 1754.18,
  'adjVolume': 4016353,
  'close': 1731.01,
  'date': '2020-12-18T00:00:00+00:00',
  'divCash': 0.0,
  'high': 1755.11,
  'low': 1720.22,
  'open': 1754.18,
  'splitFactor': 1.0,
  'volume': 4016353}]

Until we add a convenience method for this directly to the library (perhaps with parallel fetching or some sort of rate limiting handled in the library), how does this look? Admittedly it has more fields than you requested, but since we can't prevent the backend from sending them yet, I figured it's OK to include them all.

# assuming you instantiated a client = TiingoClient() somewhere up above
def get_latest_prices(tickers): 
    return [ 
        client.get_ticker_price(ticker) for ticker in tickers
    ]

[datatalking]

@hydrosquall previously you mentioned some sort of rate limiting handled in the library has this been asked before as I'm working on something similar and could try building it.

The one I have now tracks API calls, as n number per month, day, hour, minute options.

Tiingo has the free and pro tier, do we have pro tier features in our code?

Free Tier
500 unique symbols a month 50 requests an hour 1000 requests a day

[hydrosquall]

Hi @datatalking , thanks for your ideas!

Tiingo has the free and pro tier, do we have pro tier features in our code?

Currently the Python SDK doesn't have any knowledge about whether the user is on a free or pro tier. Any sort of rate limiting would be enforced by the Tiingo backend. What did you have in mind for what the SDK would do with this information?

Rate limiting

I'm mixed about whether this is something we should build directly into Tiingo-python (since that could mean adding new dependencies), vs have a documentation page indicating how to wrap your Tiingo calls in something that manages API calls (totals, rates, etc). If you have a code snippet in mind, we could add it to the public docs and see if people use it before committing to adding something like this to the core SDK.