REGR: NotImplementedError: Prefix not defined when slicing offset with loc
State: closed

- [x] closes #46671
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] Added an entry in the latest `doc/source/whatsnew/v1.4.4.rst` file if fixing a bug or adding a new feature.


Labels:
name: Datetime
description: Datetime data dtype
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves

Comments:
Hello @CloseChoice! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:





There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers: 

##### Comment last updated at 2022-08-22 20:30:59 UTC
The problem in here is that we expect different types in this `parsing.parse_time_string` which are not consistent with the `rule_code` attribute, e.g.
` pandas/tests/series/indexing/test_datetime.py::test_getitem_setitem_periodindex` where the type of `self.freq` is `pandas._libs.tslibs.offsets.Hour`. This class implements the `_prefix` attribute.
But in the newly added test `test_getitem_iloc_dateoffset_days` `self.freq` has the type `pandas._libs.tslibs.offsets.DateOffset` which does inherit the `_prefix` method from `BaseOffset` as an [`NotImplementedError`](https://github.com/pandas-dev/pandas/blob/main/pandas/_libs/tslibs/offsets.pyx#L553).

Is this on purpose? Shouldn't we be able to fix this issue by just implementing the `_prefix` method correctly?
This pull request is stale because it has been open for thirty days with no activity. Please [update](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#updating-your-pull-request) and respond to this comment if you're still interested in working on this.
@CloseChoice thanks for the PR! (and sorry for that automated comment, it's not you who didn't update the PR, but it's a review that was lacking)

I merged in main to fix the conflicts
> Looks good to me.
> 
> I think we can try to clean up the situation around `rule_code` in another PR that is not targeted for 1.4.x (should DateOffset have that defined? Should we actually pass something (greqstr/inferred_freq) to the parse function if rule_code isn't defined?)

First things first: Thanks once again for helping out and the very friendly tone of your comments. I really appreciate it.

Yes, I totally agree that we should clean up `rule_code` at some point, I am also very willing to dive into that. 
When I investigated the situation around `rule_code` there are a couple of things we could do:
1. One thing that came to my mind is to add `rule_code` for DateOffsets. This would help us get rid of the `except` part in this PR
2. Refactor `parse_date_string` to not need this information at all. As you mentioned [in the other](https://github.com/pandas-dev/pandas/pull/47547#discussion_r950673404) `freq` is actually used in very limited cases (as I can see, it only used in the chain `parse_time_string -> parse_datetime_string_with_reso -> _parse_dateabbr_string -> quarter_to_myear -> get_rule_month` and in `_parse_dateabbr_string` where it is checked against `M`. So there might be a good way of working around this by finding the `rule_month` (as given by `get_rule_month`) and checking for `M` first and implementing a special case for this somewhere not so deep down in the chain.

There are also a couple todos written in the code, so I think we could improve here quite some things.
Thanks @CloseChoice !

> When I investigated the situation around `rule_code` there are a couple of things we could do:

Could you move that summary to a new issue to track this?