Closed JBGreisman closed 1 month ago
I'm open to the idea of the *args
/**kwargs
paradigm and we do use it elsewhere. Personally, I find these to be very frequently used methods, so I enjoy having the easy introspection of call signature and correct docstrings (that don't mention pandas
specifics). That was the main rationale for keeping it this way. Definitely open to reconsidering if you feel otherwise though.
I'm open to the idea of the
*args
/**kwargs
paradigm and we do use it elsewhere. Personally, I find these to be very frequently used methods, so I enjoy having the easy introspection of call signature and correct docstrings (that don't mentionpandas
specifics). That was the main rationale for keeping it this way. Definitely open to reconsidering if you feel otherwise though.
I think there are good reasons not to use *args
/ **kwargs
in this case. It's quite an important method. I was just trying to safeguard against changes in Pandas breaking the CI. I think maybe the CI should break in this case. We should hear about it whenever their call signature changes. I'm good with this.
There was an update to the pandas API in v1.5 that changed the
pd.DataFrame.reset_index()
call signature. This PR updates the call signature ofrs.DataSet.reset_index()
and adds tests to confirm the consistency of the call signature between:rs.DataSet.reset_index()
andpd.DataFrame.reset_index()
rs.DataSet.set_index()
andpd.DataFrame.set_index()