OpenBBTerminal
OpenBBTerminal copied to clipboard
OpenBB-finance
[Bug]stocks/ba/queries - google_view.py: SettingWithCopyWarning: A value is trying to be set on a copy of a slice from a DataFrame.
stocks/ba/queries - SettingWithCopyWarning: A value is trying to be set on a copy of a slice from a DataFrame.
Does not break the terminal, but prints a warning message.
(🦋) /stocks/ba/ $ queries
/Users/danglewood/GitHub/OpenBBTerminal/openbb_terminal/common/behavioural_analysis/google_view.py:223: SettingWithCopyWarning:
A value is trying to be set on a copy of a slice from a DataFrame.
Try using .loc[row_indexer,col_indexer] = value instead
See the caveats in the documentation: https://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#returning-a-view-versus-a-copy
df_related_queries["value"] = df_related_queries["value"].apply(
Top GME's related queries
┏━━━━━━━━━━━━━━━━━┳━━━━━━━┓
┃ query ┃ value ┃
┡━━━━━━━━━━━━━━━━━╇━━━━━━━┩
│ stock gme │ 100% │
├─────────────────┼───────┤
│ amc │ 29% │
├─────────────────┼───────┤
│ amc stock │ 24% │
├─────────────────┼───────┤
│ gme price │ 23% │
├─────────────────┼───────┤
│ gme stock price │ 14% │
├─────────────────┼───────┤
│ gme share │ 7% │
├─────────────────┼───────┤
│ gme share price │ 6% │
├─────────────────┼───────┤
│ reddit │ 6% │
├─────────────────┼───────┤
│ gme reddit │ 6% │
├─────────────────┼───────┤
│ bb │ 5% │
└─────────────────┴───────┘
Learned some things yesterday:
- for the stocks/options module - this message only occurs with certain expirations. TSLA, for example, only displays this error for 9/16/2022.
- yesterday, this was exp 4, but today it's exp 3 and the error persists, so the warning isn't related to the index of the expiration
- the stocks/ba module appears to show this warning every single time. I tested with BBBY, TSLA, GME, and AAPL
It occurred to me that this expiration is a "standard" expiration instead of a weekly one. So i checked other expirations and was unable to reproduce the warning for:
- 10/21/2022 (standard expiration)
- 11/18/2022 (standard expiration)
- 12/16/2022 (standard expiration)
Needs more investigation. My current theory is that it may be related to the expiration being a "standard" within a month that also contains weekly ones. Not sure why that would be the case, but I'm going to have to keep testing.
Does the command still work?
If it's just the warning that's usually just a pandas thing like the warning says
I did some more research last night and found a couple of things:
for stocks/options
the warning occurs only when some of the options in the chain have implied volatility <= 0. Those rows are filtered out in yfinance_model, line 72:
df_list = [x[x["impliedVolatility"] > 0] for x in df_list]
On line 80, when greeks are set, we're now modifying a slice of the original DataFrame. This only happens if there isn't enough activity for a certain option and the price remains constant, which is why this warning only appears intermittently.
There's no reason to keep the original df, so adding a .copy() statement will permanently handle the warning
df_list = [x[x["impliedVolatility"] > 0].copy() for x in df_list]
for stocks/ba
I don't know why the warning is intermittent and it stopped appearing mid-testing last night (seems to be back this morning).
But, I actually found an unrelated issue that does break the functionality.
The --export flag no longer works for stocks/ba:
I can fix this pretty easily, but it's related to the same code that is likely causing the SettingWithCopyWarning. Should I make it a separate issue?
queries --export csv does break it in my installer package version.
Do we need a new issue, or, just keep this one evolving because it is the same command it was raised for, @DidierRLopes?
My two cents:
I can fix the export problem and both SettingWithCopyWarnings immediately with just a few tweaks. I am just working on updating the pytests because they don't appear to be properly checking whether the --export flag works correctly.
The other error (related to Google returning 429) is going to be a bit more involved. We'll have to look at the core _get_data() function and figure out how to make it return something that is acceptable to all of the other functions that call it. Right now, it raises an exception, but then it still returns the rest of the JSON response. Shouldn't be too tricky, but it's definitely a separate set of considerations, in my opinion.