Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is item[1] the correct value to return as default value? #62

Open
DavideViolante opened this issue Jul 30, 2022 · 1 comment
Open

Is item[1] the correct value to return as default value? #62

DavideViolante opened this issue Jul 30, 2022 · 1 comment
Labels
question Further information is requested

Comments

@DavideViolante
Copy link
Owner

DavideViolante commented Jul 30, 2022

See discussion in #61
After the mentioned PR this package is returning also some other values, see readme.

@DavideViolante DavideViolante added the question Further information is requested label Jul 30, 2022
@yortug
Copy link

yortug commented Aug 7, 2022

My thoughts are that the default return value probably shouldn't be the high or the low values, so it shouldn't be set to item[2] or item[3], as they could fluctuate heavily on a high volatity day of trading.

However, it's a bit harder to decide whether it should be the open or the close price (i.e. should it be item[1] or item[4]?).

We have value set as the open price at the moment (i.e. item[1]).

I personally think the close price (i.e. item[4]) would be the safest option in terms of the data understanding. When you query the close price, and the market is still open, you'd expect (hope) the API simply wouldn't return a result. This might give the end user a clue as to what price they actually are working with, they aren't getting a return value for the current day because the market hasn't closed yet.

However, I do think that the open price (i.e. item[1]) has its advantages too. It has the benefit of (hopefully) returning a value even if the market hasn't closed yet.

TL;DR - My opinion is that item[1] and item[4] would be fine, I'd say item[4] has the slight edge, but it's really up to the end user's intended use case / understanding. As long as the end user knows which value they are utilising, and has access to all the other values too (as they do now), then I don't think we can go too wrong! 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants