Add support for additional metaclasses of proxies and use for ExcelWriter

[vyasr]

Description

The ExcelWriter supports the abstract os.PathLike interface, but we would also like that support to be reflected in the class's MRO. Doing so is slightly complicated because os.PathLike is an ABC, and as such has a different metaclass. Therefore, in order to add os.PathLike as a base class, we must also generate a suitable combined metaclass for our ExcelWriter wrapper.

This change ensures the isinstance(pd.ExcelWriter(...), os.PathLike) returns True when using cudf.pandas.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[mroeschke]

Looks good. Might be good to add a unit test that an isinstance check on this object with os.PathLike works

[vyasr]

I uncovered another strange thing while writing a test here. Given this script

# test.py
import pandas as pd
def test_pathlike():
    print(pd.ExcelWriter("foo.xlsx").__class__)

Without the changes in this PR, I see the following behavior if I run that test inside the repo:

(rapids) coder _ ~/cudf $ pytest -p cudf.pandas -s test.py 
...
test.py <class 'pandas.io.excel._openpyxl.OpenpyxlWriter'>
...
(rapids) coder _ ~/cudf $ pytest -s test.py 
...
test.py <class 'pandas.io.excel._openpyxl.OpenpyxlWriter'>

On the other hand, if I run from outside the repo I see this

(rapids) coder _ ~ $ pytest -p cudf.pandas -s test.py
...
test.py <class 'pandas.io.excel._base.ExcelWriter'>
...
(rapids) coder _ ~ $ pytest -s test.py
...
test.py <class 'pandas.io.excel._openpyxl.OpenpyxlWriter'>
...

Note that when run outside the repo the class shows up differently. I don't know why that is, but it makes testing from inside the repo difficult because the issue is masked. I'll dig a little more next week, this is as far as I got today.

@shwina or @wence- if this makes quick sense to you feel free to jump in.

[vyasr]

I need to come back to this and investigate further. @galipremsagar or @wence- if the above result makes sense to you let me know, but no need to spend much time investigating if it doesn't. I'll come back to this when I have a bit of time free.

[vyasr]

OK @mroeschke I've added a test here. The issue above is not related to this PR, and the behavior can be observed even without it. The issue is that the pandas ExcelWriter overrides __new__ to support returning instances of different classes depending on the engine. In this case, while we get the right behavior in cudf.pandas, we do not have the correct repr because we only have the top-level class name available to us and not the real class selected at runtime. As a result, the repr of our object looks wrong even though the real object is correct.

I think fixing this issue is out of scope for this PR, but it's something we may need to investigate further. In pandas >=2.0, with the new index class hierarchy is it still possible to instantiate an index with the base index constructor that doesn't isn't of type Index now that the numerical and string index types are gone? For example, categorical indexes I believe must be constructed with the pd.CategoricalIndex constructor now, right? If there are any exceptions, I would expect them to exhibit the same behavior.

[galipremsagar]

OK @mroeschke I've added a test here. The issue above is not related to this PR, and the behavior can be observed even without it. The issue is that the pandas ExcelWriter overrides __new__ to support returning instances of different classes depending on the engine. In this case, while we get the right behavior in cudf.pandas, we do not have the correct repr because we only have the top-level class name available to us and not the real class selected at runtime. As a result, the repr of our object looks wrong even though the real object is correct.

I think fixing this issue is out of scope for this PR, but it's something we may need to investigate further. In pandas >=2.0, with the new index class hierarchy is it still possible to instantiate an index with the base index constructor that doesn't isn't of type Index now that the numerical and string index types are gone? For example, categorical indexes I believe must be constructed with the pd.CategoricalIndex constructor now, right? If there are any exceptions, I would expect them to exhibit the same behavior.

We have a similar problem for Timedelta and Timestamp classes that can return pd.NA when None is passed, the problem there was solved by having Timestamp_Timedelta__new__ implemented and then assigning it to __new__. I think this PR is doing more, like letting the metaclasses be combined.

[galipremsagar]

I re-ran the CI to see the latest diff of the tests passing/failing.

[vyasr]

It claims to be a big increase of 1.38% :D do you believe it? I don't.

[galipremsagar]

It claims to be a big increase of 1.38% :D do you believe it? I don't.

It's most likely because the nightly run that happened yesterday doesn't have all the changes of this branch. But since there is no decrease, we can say this is a safe change 👍

[vyasr]

/merge