CLN: Remove int32 and float32 dtypes from IntervalTree #30598
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There isn't a practical way to actually get an
IntervalTree
withint32
/float32
dtypes sinceIntervalIndex
is backed by two pandas indexes and we don't have aInt32Index
orFloat32Index
. These indexes are used to create the underlyingIntervalTree
that backs anIntervalIndex
, so we're guaranteed to haveint64
/float64
dtype data when initializing.The only way that comes to mind that a user could create an
IntervalTree
withint32
/float32
dtype would be by explicitly initializing a standaloneIntervalTree
withint32
/float32
arrays, which doesn't seem particularly likely.This should also help with build times as it results in 8 less node classes being generated.
Didn't add a whatsnew note since I don't think
IntervalTree
is user facing (could be wrong?) but can add one if desired since this is technically a breaking change.