DEPR: na_sentinel in factorize
State: closed

- [x] closes #46910 (Replace xxxx with the Github issue number)
- [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 an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

The NotImplementedError will be removed as part of #46601

Labels:
name: Missing-data
description: np.nan, pd.NaT, pd.NA, dropna, isnull, interpolate
name: Algos
description: Non-arithmetic algos: value_counts, factorize, sorting, isin, clip, shift, diff
name: Deprecate
description: Functionality to remove in pandas

Comments:
Hello @rhshadrach! 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-06-24 18:33:26 UTC
The warning handling in algorithms.factorize isn't my favorite, but i'll take your word for it that this is the best viable option.
needs rebase, one nitpick, otherwise LGTM
> The warning handling in algorithms.factorize isn't my favorite, but i'll take your word for it that this is the best viable option.

The other option is to use catch_warnings when the call to EA.factorize is made from within pd.factorize. I typically try to avoid using it, but perhaps this is a place where it's worth it. It would certainly simplify that logic (which I myself am not a fan of).
@jorisvandenbossche - friendly ping
Thanks @jorisvandenbossche - changes made and ready for another review.

> For testing, I think it would be good if we have one of our test extension arrays (eg decimal) to still have the old signature, to ensure that we don't start to error for that

I don't think there is decimal, so I did this for datetimelike. It has the easiest implementation to change and doesn't generate warnings on its own (it uses super to do that), so seemed like the best option. Plus it also starts with a 'd' :D
Encountered a minor difficulty with the warnings and leaving TimelikeOps with the old signature. In order to not get the warning on import of pandas, need to special case it in `__init_subclass__`. However, as this "method" is run at "import time", we can't even import DatetimeArray et al (gives circular imports) to test whether `cls == DatetimeArray`. The best *I think* we can do is check it's name, which is not exactly ideal. 

With the current implementation, worst case is some code does not get warned to update the signature for classes named "TimelikeOps", "DatetimeArray", "TimedeltaArray".
@jreback @jorisvandenbossche friendly ping.
@rhshadrach thanks for the updates! Looks good to me from a quick look. I won't be able to further look at it the coming two weeks, so don't wait on me to move forward here
Thanks @rhshadrach. Follow ups can be made as needed 
> @rhshadrach thanks for the updates! Looks good to me from a quick look. I won't be able to further look at it the coming two weeks, so don't wait on me to move forward here

Thanks @jorisvandenbossche; if you do end up circling back, let me know if you have any more comments and happy to do a followup.