Pandas version checks

  • [x] I have checked that this issue has not already been reported.

  • [x] I have confirmed this bug exists on the latest version of pandas.

  • [x] I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import sys

import pandas as pd

# Envo. must have "pydev-pycharm", install with:
# pip install pydevd-pycharm
from _pydevd_bundle.pydevd_user_type_renderers import UserTypeRenderer, parse_set_type_renderers_message
from _pydevd_bundle.pydevd_user_type_renderers_utils import try_get_type_renderer_for_var

# Payload extrated from PyCharm's PyDev runtime. Contains the payload provided by the IDE's Java side,
# built from a sample customizing. It contains two "Custom Views", one for builtins.object (working fine)
# and one for pandas.DataFrame (not working).
SAMPLE_TR_CONFIG_MESSAGE = """RENDERERS 9   builtins.object builtins.object object  C:/Program Files/JetBrains/PyCharm 2025.2.0.1/plugins/python-ce/helpers/typeshed/stdlib/builtins.pyi    1   0   "DBG:"+ type(self).__name__ 1   0   9   pandas.DataFrame    pandas.DataFrame    pandas.core.frame.DataFrame <PYTHON_PATH>/Lib/site-packages/pandas-stubs/core/frame.pyi 0   0   "DBG:"+ type(self).__name__ 1   0"""

def main() -> None:
    pass
    renderers = parse_set_type_renderers_message(SAMPLE_TR_CONFIG_MESSAGE)
    df = pd.DataFrame({"dmmy": map(float,range(8))})
    obj = object()

    object_type_renderer: UserTypeRenderer = try_get_type_renderer_for_var(obj, renderers)
    dataframe_type_renderer: UserTypeRenderer = try_get_type_renderer_for_var(df, renderers)

    print(f'Type Renderer for builtins.object | {object_type_renderer}')
    print(f'Type Renderer for pandas.DataFrame | {dataframe_type_renderer}')

    # Should Output
    """
    Type Renderer for builtins.object | <_pydevd_bundle.pydevd_user_type_renderers.UserTypeRenderer object at 0x0000048DDD0B2950>
    Type Renderer for pandas.DataFrame | None
    """


if __name__ in {"__main__", "__mp_main__"}:
    sys.exit(main())

Issue Description

As described at the referenced comment at "ENH: 55178":

The addition of the decorator set_module for DataFrames and Series, as far as i managed to verify, seems to be causing issues in PyCharm's Type Renderers functionality. When a Custom Data View is created at the IDE, we need to inform the target type, and the settings engine will validate the input against stubs and save the full qualified name it gets from them! Since no such abreviation is in place at the stubs, it will record "pandas.core.frame.DataFrame" as the qualified name.

Then when JetBrains's PyDev fork, that is base for PyCharm debugger, search for Type Renderers customized for the DataFrame, it compares the abreviated "qualname" from runtime (basically f'{type(obj)module}.{type(obj)name}' that will make for "andas.DataFrame") with the one he recorded from the customizing based on the stubs (that will be "pandas.core.frame.DataFrame").

There's also some hard-codes for pandas.core.frame.DataFrame and pandas.core.frame.Series at a "Table Provider" routine, used to determine PyCharm's "Data View" tool engine for pandas's DataFrames and Series, but that i believe should be addressed over there?

Thanks!

Expected Behavior

Considering the reproducible provided, "pydevd-pycharm" should provide a "UserTypeRenderer" object from the call performed to "try_get_type_renderer_for_var", since it was configured correctly at PyCharm's Type Rederers settings.

Installed Versions

None

For some reason "show_versions" return None. I identified this issue while experimenting with pandas release provided at the scientific nightly conda channel, where we have a pandas 3.0.0 release.

Comment From: jorisvandenbossche

Just to be clear, the issue you have is not related to the technical use of the @set_module decorator, I suppose? But because of changing the value for pd.DataFrame.__module__ from 'pandas.core.frame' to 'pandas' (regardless of how we did that)

We know that some people will rely on a hardcoded 'pandas.core.frame', and that this is a breaking change (that is also the reason why we are doing this for a major 3.0 release). So in general, I think we expect that when people run into that, it should be fixed where this full path is relied upon (but I see you also already opened a PR on the pycharm side that should address this?)

Comment From: dangreb

Just to be clear, the issue you have is not related to the technical use of the @set_module decorator, I suppose? But because of changing the value for pd.DataFrame.__module__ from 'pandas.core.frame' to 'pandas' (regardless of how we did that)

We know that some people will rely on a hardcoded 'pandas.core.frame', and that this is a breaking change (that is also the reason why we are doing this for a major 3.0 release). So in general, I think we expect that when people run into that, it should be fixed where this full path is relied upon (but I see you also already opened a PR on the pycharm side that should address this?)

Preciselly! I commented at the ENH thread and oppened the issue for two reasons: as a means to connect everything and everyone, as a record of the analysis in case other IDE related issues may arise.

I considered the latter important as i'm restricting my scope to PyCharm as of now! At that, i'm more convinced, from my findings, that a solution for this case should be made at pycharm side, so built a initial/functional implementation that i'm planing to follow up.

The way i see, directing it to the 3.0 mileestone is indeed adequate. Would you say we wait untill the jetbrains side is resoled and then i close this issue? It's a suggestion anyway, please procees as you will!