DEPR: concat ignoring empty objects
State: closed

- [x] closes #39122 (Replace xxxx with the GitHub issue number)
- [x] closes #22186
- [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
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] 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/vX.X.X.rst` file if fixing a bug or adding a new feature.

cc @jorisvandenbossche 

Labels:
name: Reshaping
description: Concat, Merge/Join, Stack/Unstack, Explode
name: Deprecate
description: Functionality to remove in pandas
name: Stale

Comments:
Rereading some of the previous discussions, would you be OK with start doing this deprecation for empty objects _that are not object/float dtype_? (since those are used as generic "empty" dtype)
> Rereading some of the previous discussions, would you be OK with start doing this deprecation for empty objects that are not object/float dtype? (since those are used as generic "empty" dtype)

I'm not dead-set against that, but would like to push down this road a bit further first.  IIRC the object/float (in particular float) cases were mostly a sticking point in the all-nan cases more than the empty cases.
> also, this is kind of hard to review, it looks like you're both refactoring and introducing the deprecation warning - any chance to split out the refactoring into a precursor PR please? (or to write a few changes summarising the changes)

I think I can refactor out as a precursor, coming up shortly.
Precursor #53260
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.
@jorisvandenbossche @MarcoGorelli gentle ping
My apologies for the slow response here, but I would like to get back to this one point (https://github.com/pandas-dev/pandas/pull/52532#issuecomment-1503757602):

> > Rereading some of the previous discussions, would you be OK with start doing this deprecation for empty objects that are not object/float dtype? (since those are used as generic "empty" dtype)
> 
> I'm not dead-set against that, but would like to push down this road a bit further first. IIRC the object/float (in particular float) cases were mostly a sticking point in the all-nan cases more than the empty cases.

I am not fully sure how to interpret the "push down this road a bit further first", but so you would not necessarily be against doing this deprecation only for non-object/float dtypes? 

(I am also happy to do a follow-up PR for that)
@jbrockmendel when you have a moment, could you also address this test failure (looks like this PR could have used a rebase)

```
FAILED pandas/tests/groupby/test_groupby.py::test_indices_concatenation_order - AssertionError: Did not see expected warning of class 'FutureWarning'
```
> when you have a moment, could you also address this test failure (looks like this PR could have used a rebase)

will take a look now.

> I am not fully sure how to interpret the "push down this road a bit further first", but so you would not necessarily be against doing this deprecation only for non-object/float dtypes?

IIRC at the time of that comment there were other review comments to address (https://github.com/pandas-dev/pandas/pull/52532#discussion_r1163061498) and i wanted to see how "clean" this PR would be once those were addressed.

Also as I said in that comment, my understanding of the motivation to limit to only non-object/float cases was about the all-NA case, not the empty case.  What would the motivation be to special-case the deprecation here?