Feature proposal for ticker.calendar

[rickturner2001]

Feature proposal

This is a feature proposal for Ticker.calendar. the table is scraped from https://finance.yahoo.com/calendar/earnings?symbol=<ticker> , since the calendar is an html table, we can parse that with pandas.read_html

Usage

I am somewhat skeptical about the way I structured the calendar API, better suggestions to handle get_next are welcome

import yfinance as yf

ticker = yf.Ticker("AAPL")

# Returns an instance of CalendarData
calendar = ticker.calendar


earnings_calendar = calendar.get_calendar()  # Returns None | DataFrame

# get_next returns CalendarData and get_calendar returns None | DataFrame
next_earnings = calendar.get_next().get_calendar()

print("earnings: ")
if earnings_calendar is not None:
    print(earnings_calendar.tail(10))
print("\nnext earnings")
if next_earnings is not None:
    print(next_earnings.tail(10))

next_earnings = calendar.get_next()
print("\nnext earnings")
if next_earnings is not None:
    print(next_earnings.get_calendar().tail(10))

when get_next, which calls _get_calendar raises a ValueError then we know that there are not tables to be parsed.

In the example above if get_next() reaches the end of the earnings list, then we keep returning the last batch

[ValueRaider]

I can't think of a fundamentally better way. If it's too easy, users will spam-fetch entire table.

So just normal feedback:

• make get_next append, not overwrite
• Use TickerData.get()
• stop fetching when nothing returned
• maybe reduce size (of first fetch)? Think of the typical use case, which I imagine is "get recent/soon earnings date"

Update: Ticker.get_earnings_dates() already fetches this data, but differently. Ticker.calendar used to fetch from different page.

[rickturner2001]

• Make get_next append, not overwrite
• Use TickerData.get()
• stop fetching when nothing returned
• maybe reduce size (of first fetch)

If you're concerned with reducing the first fetch because of A. problems with users abusing the API or B. performance, then I have two things to say

• We are not using yahoo finances API but the website. We are literally parsing the HTML
• Parsing the HTML which takes us to point B. This is already slow and the difference in time we have to wait for requests with size=1 or size=100 is neglectable

If on the other hand you'd like to have this as a handy feature, then we could have a separate method for that, that's for sure

[rickturner2001]

I think this is a fair implementation, although I would much rather hit the endpoint that provides JSON data instead of having to parse the entire HTML.

[ValueRaider]

Fair points, the implementation is fine.

But naming. ICYMI: Ticker.get_earnings_dates() already fetches this data but differently, Ticker.calendar used to fetch from different page. Would be good to have consistent function names.

[rickturner2001]

Ticker.get_earnings_dates() is doing basically the same thing. Although it is not using a class to wrap the data. I am going to delete that implementation and overwrite it with this one, then I'll delete the calendar property and get_earnings_date will work with the CalendarData class. How does that sound?

[ValueRaider]

I think we're thinking the same thing, so go ahead. Just copy over the post-fetch formatting.

[rickturner2001]

Tests are passing and I think you'll be satisfied with the naming convention. Something to notice is that I deleted some of the unused properties.

[ValueRaider]

I was hoping you would preserve the API and just replace internals of get_earnings_dates(). If you want to change the API, then first print deprecated warnings to give users a change to migrate. Like Pandas does, and here:

yfinance/yfinance/base.py

Line 138 in 5b1605b

utils.print_once(f"yfinance: Ticker.history(debug={debug}) argument is deprecated and will be removed in future version. Do this instead: logging.getLogger('yfinance').setLevel(logging.ERROR)")

Also, technically you aren't returning earnings but EPS. Ticker.earnings used to return this:

[rickturner2001]

I apologize for my absence but I had to take some time off. I will close this PR and open a new one without disregarding the existing api and by properly deprecating the current implementation