pandas
pandas copied to clipboard
DOC/TST: Clarify Series.str.get supports passing hashable label
- [ ] closes #47911 (Replace xxxx with the Github issue number)
- [x] Tests added and passed if fixing a bug or adding a new feature
- [x] All code checks passed.
- [ ] Added type annotations to new arguments/methods/functions.
- [x] Added an entry in the latest
doc/source/whatsnew/vX.X.X.rstfile if fixing a bug or adding a new feature.
NO! https://github.com/pandas-dev/pandas/issues/47911#issuecomment-1201676711
i is only positional in the documentation... it's definitely not strictly positional in current functionality. https://github.com/pandas-dev/pandas/blob/14de3fd9ca4178bfce5dd681fa5d0925e057c04d/pandas/core/strings/object_array.py#L249:L257
I am starting to agree with @BeRT2me, I don't think we can change this outright.
I think the fact that str.get works for object with a dict element series was just poorly described as there were past issues explaining some usage of this functionality. e.g. https://github.com/pandas-dev/pandas/issues/20671
I would be +1 to keep supporting this (although there's cognizant dissonance with str.get working on dict elements). I think clarifying pos can be a hashable dict label and adding unit tests would be good instead.
Do you want to deprecate or add this to the documentation?
How Series.str works for anything (list, tuple, dict, set, etc.) that isn't a string hasn't made much sense logically for a while.
In my opinion, mirroring how dict.get does things by allowing a default value to be specified if the key/index isn't found would be a positive change.
Not forgetting to update the documentation to match would be nice as well...
I think if we have a list of dictionaries like
lst_of_dict = [
{"name": "Hello", "value": "World"},
{"name": "Goodbye", "value": "Planet"}
]
we could construct a DataFrame by pd.DataFrame(lst_of_dict), and DataFrame supports pass default value to DataFrame.get. I have no idea about whether we should deprecate pass non-integer type in Series.str.get or not.
Should _str_get supports default value argument as @BeRT2me suggested?
Should
_str_getsupports default value argument as @BeRT2me suggested?
I would save that for another issue to discuss
Appears some doc checks are failing
Honestly, I don't know what's going wrong from the Traceback of the failed check.
Might want to merge in the main branch into this PR. I believe there was some doc failures that were fixed recently.
Hello @xr-chen! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:
There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers:
Comment last updated at 2022-08-09 01:03:20 UTC
Thanks @xr-chen