CLN: use RangeIndex._range instead of RangeIndex._start etc. #26578
Conversation
topper-123 force-pushed the clean_RangeIndex branch from 8f431bd to 6b15312 Compare 
Codecov Report
@@ Coverage Diff @@ ## master #26578 +/- ## ========================================== - Coverage 41.79% 41.67% -0.13% ========================================== Files 174 174 Lines 50643 50617 -26 ========================================== - Hits 21168 21094 -74 - Misses 29475 29523 +48
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@ ## master #26578 +/- ## ========================================== - Coverage 91.84% 91.84% -0.01% ========================================== Files 174 174 Lines 50643 50624 -19 ========================================== - Hits 46515 46494 -21 - Misses 4128 4130 +2
Continue to review full report at Codecov.
|
| .. deprecated:: 0.25.0 | ||
| Use ._range.start or .start instead. | ||
| """ | ||
| return self._range.start |
There was a problem hiding this comment.
Unfortunately, fast_parquet uses _start etc. which I hadn't predicted, when I started this PR. So this proposes deprecating the attributes _start, _stop and _step, and removing them in 1.0.
Thuis can be bit of a nuisance for upstream maintainers, so don't know if there's opposition to this, but this PR has several benefits also, so there's a trade-off.
| Some problems, closing temporqrily. |
1 participant
git diff upstream/master -u -- "*.py" | flake8 --diffMake RangeIndex use python's
rangeinternally, rather than the three scalars_start,_stopand_step.Python3's
rangehas several nice properties, that were not available inxrangein Python2. For example it's sliceable, and has.indexandcountand various magic methods. These can be used in Pandas, rather than maintaining Pandas-specific code, offering cleaner code and possibly faster operations.