Skip to content

DOC: add whatsnew note about __module__ changes for the public API #62784

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 23, 2025
Merged

DOC: add whatsnew note about __module__ changes for the public API #62784

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions doc/source/whatsnew/v3.0.0.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -515,6 +515,22 @@ If we had passed ``pd.Int64Dtype()`` or ``"int64[pyarrow]"`` for the dtype in th

With ``"mode.nan_is_na"`` set to ``False``, ``ser.to_numpy()`` (and ``frame.values`` and ``np.asarray(obj)``) will convert to ``object`` dtype if :class:`NA` entries are present, where before they would coerce to ``NaN``. To retain a float numpy dtype, explicitly pass ``na_value=np.nan`` to :meth:`Series.to_numpy`.

The ``__module__`` attribute now points to public modules
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The ``__module__`` attribute on functions and classes in the public API has been
updated to refer to the preferred public module from which to access the object,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
updated to refer to the preferred public module from which to access the object,
updated to refer to the preferred public module from which to access the member of the API,

I don't think using "object" here makes sense in referring to "function"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the "everything in Python in an object", I think this makes sense.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hadn't heard that statement before. But it makes sense. I'll leave it up to Joris if he wants to change it.

Copy link
Member

@rhshadrach rhshadrach Oct 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also good with object. This statement also applies to class instances (e.g. pd.NA).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I wanted to avoid repeating "function or class".

Will leave it as is then

rather than the module in which the object happens to be defined (:issue:`55178`).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
rather than the module in which the object happens to be defined (:issue:`55178`).
rather than the module in which the member happens to be defined (:issue:`55178`).


This produces more informative displays in the Python console for classes, e.g.,
instead of ``<class 'pandas.core.frame.DataFrame'>`` you now see
``<class 'pandas.DataFrame'>``, and in interactive tools such as IPython, e.g.,
instead of ``<function pandas.io.parsers.readers.read_csv(...)>`` you now see
``<function pandas.read_csv(...)>``.

This may break code that relies on the previous ``__module__`` values (e.g.
doctests inspecting the ``type()`` of a DataFrame object).

.. _whatsnew_300.api_breaking.deps:

Increased minimum version for Python
Expand Down