Move more methods into SingleColumnFrame

[vyasr]

Continuation of #8115 and #8166. Moves more logic out of the Index/Series classes into the new common parent class to reduce code duplication and ensure feature parity.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (branch-21.06@92a432d). Click here to learn what that means.
The diff coverage is n/a.

@@               Coverage Diff               @@
##             branch-21.06    #8253   +/-   ##
===============================================
  Coverage                ?   82.88%           
===============================================
  Files                   ?      105           
  Lines                   ?    17910           
  Branches                ?        0           
===============================================
  Hits                    ?    14845           
  Misses                  ?     3065           
  Partials                ?        0           

---

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 92a432d...ea9331f. Read the comment docs.

[brandon-b-miller]

LGTM :)

[isVoid]

LGTM in general. In addition I would love to have more insight into how MultiIndex is (completely) shadowed away from methods in SingleColumnFrame. Could you elaborate if you don't mind?

[vyasr]

LGTM in general. In addition I would love to have more insight into how MultiIndex is (completely) shadowed away from methods in SingleColumnFrame. Could you elaborate if you don't mind?

The short answer is that I'm not doing anything, because nothing has been done in the past to fix this. MultiIndex in its current state works, but is fragile and there are lots of things that probably break in unexpected ways (like binary ops, for example). The critical methods to ensure that creating a DataFrame/Series with a MultiIndex have been correctly overridden, but try to do anything beyond that right now and you're playing with fire.

The longer answer is that I have a plan for how to resolve this issue, but it will take some more careful refactoring. In the long term, I think we should aim for a structure that looks more like this:

class Frame
class SingleColumnFrame(Frame)
class Index(Frame)
class MultiColumnFrame(Frame) # Maybe worthwhile, _if_ we can find good ways to share DataFrame and MultiIndex code
class MultiIndex(Index, MultiColumnFrame) # _If_ we did this, we would have to figure out the right order
class RangeIndex(Index)
class SingleColumnIndex(Index, SingleColumnFrame) # We would have to figure out the right order
# all the other index types inherit from Index

This inheritance would resolve your concerns. However, before we can do that we need to make it a lot easier to inherit from Index types, which is a huge pain right now because of the way we need to override __new__. After #8254 is merged I plan to make a subsequent PR that renames Index to something like BaseIndex, then remove its __new__ method and puts it into a new class Index(BaseIndex). This class will sit at the bottom of the hierarchy rather than the top, but I'll use a little metaclass hacking to hide that detail from users (basically overriding __instancecheck__ and __subclasscheck__. Assuming that works, it should then be possible to substantially simplify all the constructor logic for Index types, and I won't feel so apprehensive about more substantial modifications to the inheritance hierarchy.

[vyasr]

@gpucibot merge