DEPR: Index.contains, DatetimeIndex.offset by jbrockmendel · Pull Request #30103 · pandas-dev/pandas (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
DatetimeIndex.offset I thought was removed in #29801, but apparently slipped through the cracks.
| - Passing ``datetime64`` data to :class:`TimedeltaIndex` or ``timedelta64`` data to ``DatetimeIndex`` now raises ``TypeError`` (:issue:`23539`, :issue:`23937`) |
|---|
| - A tuple passed to :meth:`DataFrame.groupby` is now exclusively treated as a single key (:issue:`18314`) |
| - Removed the previously deprecated :meth:`Index.contains`, use ``key in index`` instead (:issue:`30103`) |
| - Removed the previously deprecated :attr:`RangeIndex._start`, :attr:`RangeIndex._stop`, :atttr:`RangeIndex._step` (:issue:`26581`) |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the min version of pyarrow that is ok here?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like the problem is in fastparquet; it fails in the most recent version 0.3.2
reverted the RangeIndex bits since fastparquet still uses them
Also, the start/stop/step were only at deprecation warning, we should maybe first elevate that to future warning?
DEPR: Index.contains, RangeIndex._start, _stop, _step DEPR: Index.contains, DatetimeIndex.offset
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add DatetimeIndex.offset to the whatsnew as well?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The offset note made it into #29801, just the actual removal fell through the cracks
Also, the start/stop/step were only at deprecation warning, we should maybe first elevate that to future warning?
Seems reasonable. Should we have a section in #6581 for DeprecationWarnings to upgrade to FutureWarnings? (or a separate tracker, but id prefer to keep it unified)
Also, the start/stop/step were only at deprecation warning, we should maybe first elevate that to future warning?
Seems reasonable. Should we have a section in #6581 for DeprecationWarnings to upgrade to FutureWarnings? (or a separate tracker, but id prefer to keep it unified)
we usually create a specific issue on that milestone, e.g. 1.1 or whatever (and/or can put on a unified tracker)
proost pushed a commit to proost/pandas that referenced this pull request
proost pushed a commit to proost/pandas that referenced this pull request
This was referenced
Feb 6, 2020