Add market Summary

[R5dan]

Supersedes #2172

[ValueRaider]

What is Summary class providing beyond just returning the dict?

[R5dan]

Sorry, thought thats how it was wanted. How do you want it? Currently it returns a MarketSummary object which has the data for that market?

[R5dan]

@ValueRaider let me know what you want it to return and then I'll mark it for review

[ValueRaider]

My mistake, I meant to question the MarketSummary class.

[R5dan]

My mistake, I meant to question the MarketSummary class.

Yes I suppose it could be a typed dict. It was meant to help provide type hints and the keys available. It also changes some of the keys names. What do you want changed?

[ValueRaider]

What happens if Yahoo adds/changes a key, or changes a type?

Python variables are already typed, don't need to keep the hints they're for parsing the JSON. Use Ticker.info for inspiration.

[R5dan]

Python variables are already typed, don't need to keep the hints they're for parsing the JSON. Use Ticker.info for inspiration

I can only see the type of dict. Not what each of the value types are?

What happens if Yahoo adds/changes a key, or changes a type?

There is still Summary._last_data I could add that to MarketSummary if you want? It can also be accessed from there though

[ValueRaider]

I can only see the type of dict. Not what each of the value types are?

Here:

>>> d = {'a':1}
>>> type(d['a'])
<class 'int'>

Reserve the Python type hints for function arguments (and return type).

[R5dan]

I can only see the type of dict. Not what each of the value types are?

Here:

>>> d = {'a':1}
>>> type(d['a'])
<class 'int'>

Sorry misunderstood you. I thought you meant static type hints in the editor.

Reserve the Python type hints for function arguments (and return type).

Ok, can I ask why though? Surely more type hints and documentation is better?

[ValueRaider]

Ok, can I ask why though? Surely more type hints and documentation is better?

Our code yes, but not the data structures returned by Yahoo - that's Yahoo's job. They can change their data structure/naming at any time without warning breaking your previous code.

[R5dan]

Ok, anyway all done. Is there anything else or shall I mark ready for review?

[ValueRaider]

I'm not sure on the refresh logic, especially because the data is very unlikely to change. I'm sensing this class can be replaced with a simple fetcher function, maybe unpack the data a bit.

[R5dan]

I'm not sure on the refresh logic, especially because the data is very unlikely to change. I'm sensing this class can be replaced with a simple fetcher function

I disagree as it does have data that changes daily: change percentage, price confidence, price hint, price, price change, previous close, tradable, marketState etc. These don't change from minute to minute (except maybe market price which does return a different value than Ticker) but from hour to hour, day to day, so caching is useful for this.

maybe unpack the data a bit.

Didn't you ask for it to not be unpacked? How do you want the data returned?

[ValueRaider]

This what I have in mind (only thought to combine your branches today): https://github.com/ranaroussi/yfinance/blob/draft/market-info/yfinance/domain/market.py

>>> mkt = yf.Market("US")
>>> print(type(mkt.status))
<class 'dict'>
>>> print(type(mkt.summary))
<class 'dict'>

The periodic refresh logic is better handled by requests_cache session https://ranaroussi.github.io/yfinance/advanced/caching.html

[R5dan]

Surely

if self._status is not None:
   return self._status

and

if self._summary is not None:
    return self._summary

defeat the purpose of caching: It is only requested once not once an hour or once a day? You might as well just have it be a getter function?

I like what you did with summary.

I think storing the data in _raw_data or something would help as it will further reduce the requests to Yahoo but also allow status to also use that data meaning they are the same.

I would also want to parse the data in status like how I have currently got.

What do you think?

The periodic refresh logic is better handled by requests_cache session https://ranaroussi.github.io/yfinance/advanced/caching.html

Forgot about that...

[ValueRaider]

It is only requested once not once an hour or once a day

That's how lazy initialization works, nice side effect as a spam guard. Use other tools to refresh, yfinance focuses on the fetch.

Parse status like this? 63698c5

Btw any way to get status fetch working with other regions beside US?

[R5dan]

Parse status like this? 63698c5

Sorry, no. Was getting confused with #2176

Btw any way to get status fetch working with other regions beside US?

I believe region doesn't effect the results and is only used for tracking, so shouldn't matter to the user. It might be that certain regions don't have access to certain data (geo blocking) but I don't know.

[R5dan]

@ValueRaider You have merged this pr with #2176. Is that what you want or do you want them as 2 separate classes?

[ValueRaider]

Merge was deliberate - only way to justify a new custom class, and make sense.

[R5dan]

What would you think of market being a class - market.status.is_open etc? Otherwise I will put them all in a dict @ValueRaider

[ValueRaider]

Abandon is_open, wait for Yahoo to complete their backend for markettime (other countries). Maybe they discovered that different markets have different times even in same country so only return US. Field status might stop being a simple open or closed.

[R5dan]

@ValueRaider How about this?

[ValueRaider]

Fetch both to ensure they are at the same time

Interesting. Why do they need to be synced?

[R5dan]

If you have some data, I think it would be best if they were synced. It seems weird to have summary from time x and then maybe 30 minutes later status. With them being synced it allows better compatibility with the data. @ValueRaider. It also means that the class is all synced when accessing data and so if that matters then it gets it. Would be annoying to fetch some data on the border of a timer period and then have it swap before you can fetch the status. Also its better to have them synced for those that need it rather than not.