CLN: Deprecate pandas.SparseArray for pandas.arrays.SparseArray

[Dr-Irv]

• closes SparseArray not in arrays module - inconsistent with IntegerArray, StringArray, etc. #30642
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry
  • in DOC: Change refs in docs from pandas.SparseArray to pandas.arrays.SparseArray #30644

Change all references in code from pd.SparseArray to pd.arrays.SparseArray . Add deprecation message for pd.SparseArray

Per comment from @TomAugspurger here: #30644 (comment), this may require discussion.

[pep8speaks]

Hello @Dr-Irv! 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! 🍻

Comment last updated at 2020-01-05 15:15:43 UTC

[jreback]

looks good. on the tests if you can simply import SparseArray at the top rather than using pd.array.SparseArray would be better. ping on green.

[Dr-Irv]

@jreback now green

[jreback]

comment for followon, @TomAugspurger ok here?

[jreback]

ok, but i'd still prefer just using SparseArray and importing it at the top, a followup for this would be ok.

[jreback]

ahh turns out need to have you rebase. can you make those import changes as well.

[TomAugspurger]

Yeah, good with these changes.

…

On Sat, Jan 4, 2020 at 5:24 PM Jeff Reback ***@***.***> wrote: ahh turns out need to have you rebase. can you make those import changes as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#30656?email_source=notifications&email_token=AAKAOIQNOEZF3ZJ63WQR32DQ4ELDNA5CNFSM4KCRC3H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIDCO2A#issuecomment-570828648>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKAOISDBFSLG7DXQKHUGWTQ4ELDNANCNFSM4KCRC3HQ> .

[jreback]

@Dr-Irv can u merge master

[Dr-Irv]

@jreback I did the merge, but CI is failing when trying to compile pandas/_libs/src/ujson/python/objToJSON.c, and I didn't touch that.

[Dr-Irv]

@jreback I did the merge, but CI is failing when trying to compile pandas/_libs/src/ujson/python/objToJSON.c, and I didn't touch that

[Dr-Irv]

@jreback I did the merge, but CI is failing when trying to compile pandas/_libs/src/ujson/python/objToJSON.c, and I didn't touch that

Seems to be reported in #30709 and fixed in #30710 so not sure what to do with many parallel things going on.

[jreback]

thanks @Dr-Irv very nice!

[jorisvandenbossche]

Consistency in our docs is certainly a good change, but I am not sure the deprecation of the top-level name is necessary. First, it's just historical reasons it is there (we have many things the way they are for historical reasons), and second, you can't create a sparse array as easily with a top-level function (pd.array, pd.date_range, etc) as you can for other array types.

Anyway, besides that comment, two practical comments on this PR:

• The deprecation for older python versions is incorrect I think: you added a dummy class that will not function at all, so this will break instead of deprecate (the test should maybe try to create a sparse array, to ensure it still works).
• I would also use a DeprecationWarning instead of a FutureWarning here first, we have time enough to change to FutureWarning later.

[jreback]

FutureWarning is correct here - why add this extra step / burden
so -1 on DeprecationWarning

[Dr-Irv]

Anyway, besides that comment, two practical comments on this PR:

• The deprecation for older python versions is incorrect I think: you added a dummy class that will not function at all, so this will break instead of deprecate (the test should maybe try to create a sparse array, to ensure it still works).

Yes, I just built an python 3.6 environment and see what you are saying, so I'll work on fixing that.