Skip to content
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.

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

DEPR: deprecate exposing blocks in core.internals #55139

Merged
merged 18 commits into from
Nov 20, 2023

Conversation

jbrockmendel
Copy link
Member

@jbrockmendel jbrockmendel commented Sep 14, 2023

Motivation: tried to clean up the blocks code bc DatetimeTZBlock and DatetimeLikeBlock are no longer really needed. Found that we can't do that bc DatetimeTZBlock is exposed in the pseudo-public API. That got me looking at internals.__init__, where comments suggest that we are importing the block subclasses for io.pytables (which no longer needs them) and io.packers (which no longer exists). So we could remove them directly, but apparently a recent PR deprecated NumericBlock and ObjectBlock so this piggy-backs on that deprecation (and adds a missing test).

In internals.api I need to deprecate DatetimeTZBlock in order to eventually get rid of it entirely. Also deprecating Block and ExtensionBlock is orthogonal just to wean downstream packages off of them.

cc @jorisvandenbossche

xref #40226

@mroeschke mroeschke added Internals Related to non-user accessible pandas implementation Deprecate Functionality to remove in pandas labels Sep 18, 2023
- Changed :meth:`Timedelta.resolution_string` to return ``h``, ``min``, ``s``, ``ms``, ``us``, and ``ns`` instead of ``H``, ``T``, ``S``, ``L``, ``U``, and ``N``, for compatibility with respective deprecations in frequency aliases (:issue:`52536`)
^^^^^^^^^^^^^^^^^^
Copy link
Contributor

Choose a reason for hiding this comment

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

doc issue

@jorisvandenbossche
Copy link
Member

As mentioned in #40226, pyarrow accesses DateimeTZBlock, but never instantiates it. So in theory that use case could easily be kept without a full working class. Now, the only reason we were using it was to pass it to make_block, and that's something we can easily remove in pyarrow, which I am doing in apache/arrow#38321.
So from pyarrow's point of view, this deprecation is fine.

@jbrockmendel
Copy link
Member Author

If there are no more comments, I plan to merge this in a week.

Copy link
Member

@jorisvandenbossche jorisvandenbossche left a comment

Choose a reason for hiding this comment

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

Can't comment on the exact line, but can you fix the stacklevel to 2 for this DeprecationWarning?

@jbrockmendel
Copy link
Member Author

Can't comment on the exact line, but can you fix the stacklevel to 2 for this DeprecationWarning?

Updated. Can you confirm this is what you have in mind

@jorisvandenbossche
Copy link
Member

Yep, that's what I meant

@jorisvandenbossche jorisvandenbossche merged commit 48899c3 into pandas-dev:main Nov 20, 2023
40 checks passed
@jorisvandenbossche jorisvandenbossche added this to the 2.2 milestone Nov 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Deprecate Functionality to remove in pandas Internals Related to non-user accessible pandas implementation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants