Why is this needed? I mean, why would we extend internal dataframe API to also be able to acceptAxisInt when we already haveAxis enum?

A lot of the codebase (mostly the query compiler) is written to call dataframe methods with a literal int rather than theAxis enum. I think it would be easier to re-wrap the axis with the enum from within dataframe methods (as is done now) than to go through and fix every instance where relevant dataframe methods are called to use the enum instead.

I don't see why we need thisAxis enum then. I really don't like this mixing ofAxis,AxisInt, and actual integers for an axis value. I think we should pick only one of the ways of interpreting an axis and then really stick to this, not introducing a variety of axis types in order to cover an existing zoo of value types.

why do we offer acopy_dtypes option only for themap operator but not forreduce andtree_reduce?

I'm not really sure, though my guess is that the frequently dimension-reducing nature of reduce/tree-reduce makes the argument less relevant for those cases. Here, I introducedcopy_dtypes as a replacement fordtypes="copy", which is a little hacky.

If I remember correctly, there was a discussion regarding limiting the usage of pandas entities in the base classes of Modin internals. Some executions may not require pandas at all and wouldn't like to deal with handling breaking changes introduced by some pandas updates.

May we define thedtypes type as something abstract likecollections.abc.Mapping so every execution would use whatever container they like?

Sure, that makes senes. Is there some other generic container that would acceptpandas.Series though? It seems like it's not a subclass ofMapping.

Could you elaborate on how the speed-up is achieved?

IMO the cell-wise execution should be beneficial in the general case against row/col-wise.

My quick and dirty micro-benchmarks show no difference between specifying an axis vs. applying cell-wise, so perhaps it's best to revert back to cell-wise operations. The hope is that for certain operators, being able to apply across a whole axis rather than having to examine each cell would provide a speedup. I will see if any other benchmarks would justify this theory.

I don't see why we need thisAxis enum then. I really don't like this mixing ofAxis,AxisInt, and actual integers for an axis value. I think we should pick only one of the ways of interpreting an axis and then really stick to this, not introducing a variety of axis types in order to cover an existing zoo of value types.

we have a special enum for this, let's use it

do we really want these parameters to be specified? it seems that they just duplicate default values

can you please elaborate? something like this is expected:

why does cell-wise map ignore all other parameters?

why do we ignoreaxis here? why does the.map_partitions call is inside of_map_axis that's supposed to call function axis-wise only?

why do we need this parameter if we have a separate method for this (map_full_axis)?

judging by the method's signature we are only supposed to allowpandas.Series to be adtype parameter, why is this logic here then? Let's either change the signature or adapt the logic somehow

do we really want these two parameters to exist at the same time? we can easily end-up in an ambiguous situation with this set of parameters:

md_df.map_select_indices(apply_indices=["a","b"],numeric_indices=[1,2,3,4,5], ...)# what's the method supposed to do?

why we're adding this here if there's no implementation? Shouldn't it be located in the base class then?