REF: Refactor signature of RangeIndex._simple_new

[topper-123]

This PR refactors RangeIndex._simple_new, so its signature is the same as Index._simple_new. This will help typing later on, as currently mypy complains about the different signatures. In short a _simple_new now expects a range as its input. As a range is immutable, the code is easy to reason about.

Additionally, the signature of RangeIndex.from_range has dropped the **kwargs part of its signature. This makes the class method a bit easier to reason about. Other classes with a from_* class method don't have a **kwargs part.

After this PR, RangeIndex will be ready for adding type hints.

EDIT; Performance improvements:

>>> rng = pd.RangeIndex(1_000_000)
>>> sl = slice(0, 900_000)
>>> %timeit rng[sl]  # slicing
7.65 µs ± 8.11 ns per loop  # master
1.85 µs ± 8.11 ns per loop  # this PR

[pep8speaks]

Hello @topper-123! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2019-06-14 08:20:11 UTC

[codecov]

Codecov Report

Merging #26722 into master will decrease coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master   #26722      +/-   ##
==========================================
- Coverage   91.78%   91.77%   -0.01%     
==========================================
  Files         174      174              
  Lines       50703    50703              
==========================================
- Hits        46538    46534       -4     
- Misses       4165     4169       +4

Flag	Coverage Δ
#multiple	90.37% <100%> (ø)	⬆️
#single	41.8% <55.55%> (-0.1%)	⬇️

Impacted Files	Coverage Δ
pandas/core/indexes/base.py	96.71% <100%> (-0.01%)	⬇️
pandas/core/indexes/range.py	98.82% <100%> (ø)	⬆️
pandas/io/gbq.py	78.94% <0%> (-10.53%)	⬇️
pandas/core/frame.py	96.88% <0%> (-0.12%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cf25c5c...1b34ac9. Read the comment docs.

[codecov]

Codecov Report

Merging #26722 into master will decrease coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master   #26722      +/-   ##
==========================================
- Coverage   91.86%   91.85%   -0.01%     
==========================================
  Files         179      179              
  Lines       50700    50702       +2     
==========================================
- Hits        46576    46574       -2     
- Misses       4124     4128       +4

Flag	Coverage Δ
#multiple	90.45% <100%> (ø)	⬆️
#single	41.11% <56.25%> (-0.07%)	⬇️

Impacted Files	Coverage Δ
pandas/core/indexes/base.py	96.71% <100%> (ø)	⬆️
pandas/core/indexes/range.py	98.82% <100%> (ø)	⬆️
pandas/io/gbq.py	88.88% <0%> (-11.12%)	⬇️
pandas/core/frame.py	96.88% <0%> (-0.12%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8374a1d...2bde25b. Read the comment docs.

[jreback]

looks fine. any comments about this api change @jorisvandenbossche @TomAugspurger

[topper-123]

I've added a new commit that's improves the performance of slices RangeIndexes:

>>> rng = pd.RangeIndex(1_000_000)
>>> sl = slice(0, 900_000)
>>> %timeit rng[sl]  # slicing
7.65 µs ± 8.11 ns per loop  # master
1.85 µs ± 8.11 ns per loop  # this PR

>>> %timeit rng[sl.stop]  # scalar
640 ns ± 15.1 ns per loop  # master
652 ns ± 14.9 ns per loop  # this PR, the same speed

So a 4 x speed improvement for slicing.

[topper-123]

Ping. Is this ok?

[jorisvandenbossche]

Is the performance improvement linked to the change in behaviour?

[topper-123]

No, it is because of that second commit, where we postpone the more expensive is_scalar check. It could as such be in a different PR.

[jorisvandenbossche]

Is there a good reason to change the init behaviour? (does it make the code less complex or does it make the life easier for users?)
If we don't have a compelling reason, I would rather leave that and just stick with the performance improvement.

[topper-123]

I've reverted the possibility to use a range to initailze the RangeIndex.

Else the code is a simplification IMO by making the signature of _simple_new align with simple_new of the other the index types, which IMO help both on understanding and on typing.

[jreback]

thanks @topper-123