Add API for yfinance

[marc-at-brightnight]

• Will come in handy when LLM can call the API and fetch data on behalf of the user

[rgaveiga]

If, on one hand, the latest PR, which eliminates that unnecessary Strategy class, is indeed one of the most significant enhancements to this lib since its inception, this PR, on the other hand, represents a significant regression. Let me clarify, the ability to retrieve market data is undoubtedly beneficial, but it should be considered as an add-on feature. It should be implemented into a separate directory, with its dedicated models.py, rather than being integrated into the core functionality of the lib. While yfinance is undeniably a very useful lib, one that I personally utilize extensively, it's worth noting, as its creator acknowledges, that it relies on the structure of Yahoo! Finance web site. If Yahoo! were to alter their website layout or even cease providing this information freely, yfinance would become obsolete. Moreover, there's another crucial aspect to consider. Another developer might submit a PR that utilizes alternative APIs (such as Interactive Brokers, Alpaca, QuantConnect, Bloomberg, etc.) to access market data. Other APIs that do not exist nowadays can be created. We need to take this into consideration when preparing the structure of the project for add-on features.

[marc-at-brightnight]

If, on one hand, the latest PR, which eliminates that unnecessary Strategy class, is indeed one of the most significant enhancements to this lib since its inception, this PR, on the other hand, represents a significant regression. Let me clarify, the ability to retrieve market data is undoubtedly beneficial, but it should be considered as an add-on feature. It should be implemented into a separate directory, with its dedicated models.py, rather than being integrated into the core functionality of the lib. While yfinance is undeniably a very useful lib, one that I personally utilize extensively, it's worth noting, as its creator acknowledges, that it relies on the structure of Yahoo! Finance web site. If Yahoo! were to alter their website layout or even cease providing this information freely, yfinance would become obsolete. Moreover, there's another crucial aspect to consider. Another developer might submit a PR that utilizes alternative APIs (such as Interactive Brokers, Alpaca, QuantConnect, Bloomberg, etc.) to access market data. Other APIs that do not exist nowadays can be created. We need to take this into consideration when preparing the structure of the project for add-on features.

So your suggestion is to make a separate directory called api/ inside optionlab/ with a yfinance.py module, with the thought being that eventually we will add more APIs?

[rgaveiga]

So your suggestion is to make a separate directory called api/ inside optionlab/ with a yfinance.py module, with the thought being that eventually we will add more APIs?

This is certainly a possibility to segregate add-on code from the core of the library. Perhaps not a directory named "api," but rather a directory with a name that more clearly suggests it contains modules providing functions for users to acquire market data for their simulations. Something akin to what I proposed for a directory containing modules implementing more advanced models (such as Heston, Merton's jump-diffusion, SABR, etc.).

[charlesverge]

Might be better to have a separate project for data retrieval and keep the prediction library standalone.