DEPR: allowing non-class returns for _constructor etc
State: closed

- [x] closes #51772 (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
- [ ] 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.

I'd be OK with leaving out the `__init_subclass__` bit and just have this be in the docs.

Labels:
name: Deprecate
description: Functionality to remove in pandas
name: Stale
name: Subclassing
description: Subclassing pandas objects

Comments:
> and since then got not even a reply to that.

We've had this discussion and I decline to go around in circles with you on this.
+1 on deprecating and making these class only

when we originally did this there was NO intention or reason to ever make these callable. it's not necessary  and just too flexible.
> We've had this discussion and I decline to go around in circles with you on this.

Sorry to chime in, but can I ask that we be a little more empathetic in written conversation please? This kind of tone can be off-putting to any newcomer who might be reading along (as well as to anyone else, really)

I'm well aware that I'm not always the best or most empathetic communicator myself, I'm just saying - let's all try to work on this
> I'm well aware that I'm always the best or most empathetic communicator myself

ah, why am I so bad at typing, of course I meant to write "I'm _not_ always" 🤦 have edited

----

Anyway, back to the issue at hand.

I've re-read through #51772. If this was never meant to work in the first place, and it was never documented to work, then it seems perfectly fine to deprecate. Especially if it simplifies the codebase and if it's not technically difficult to workaround in geopandas

Regarding the point that it'd be easy to write a code check to ensure that `.constructor` is only ever used assuming it's a class - I'm not sure I agree. At least, not statically, and anything involving inspecting annotations tends to be noticeably slower
How do we move forwards here? @jorisvandenbossche would you want a vote on this? A discussion in the community call?
shall we hold off from merging main until we find a way forwards in the discussion in the issue?
> shall we hold off from merging main until we find a way forwards in the discussion in the issue?

Is the CI clogged?  If so, sure.  Otherwise I don't see much downside to keeping this up-to-date.  Easier to rebase periodically than all at once.
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.
+1 on moving forward with this especially if there's a reasonable workaround in geopandas
@mroeschke the substantial discussion is at https://github.com/pandas-dev/pandas/issues/51772