BUG: iloc-indexing with callable has inconsistent semantics if the return type is a tuple

[wence-]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import pandas as pd
df = pd.DataFrame({"a": [1, 2, 3, 4], "b": [1, 2, 3, 4]})

scalar_value = df.iloc[(1, 0)] # a single scalar
some_rows = df.iloc[lambda df: (1, 0)] # rows 1 and 0
df.iloc[(1, 0), 0] # indexerror (as expected)
df.iloc[(lambda df: (1, 0)), 0] # indexerror (as expected)
df.iloc[lambda df: ((1, 0), 0)] # ValueError setting an array element with a sequence

Issue Description

The documentation for iloc says one possible argument for indexing can be:

A callable function with one argument (the calling Series or DataFrame) and that returns valid output for indexing (one of the above). This is useful in method chains, when you don’t have a reference to the calling object, but would like to base your selection on some value.

Now, recently, in #47989, the documentation was updated to add a final bullet point (below the just quoted text) to say:

A tuple of row and column indexes. The tuple elements consist of one of the above inputs, e.g. (0, 1).

A strict reading of this says that the callable is not allowed to return a tuple (since a tuple is not "one of the above").

OTOH, if we accept that callables are allowed in either slot for rows or columns, then the first two examples above should probably behave identically.

What are the intended semantics here?

Expected Behavior

callables should either in all cases not be allowed to return tuples for indexing, or else should have consistent semantics.

For consistent semantics, one possible mechanism to do this is to have a fixed point normalisation rule:

def normalize(key, frame):
    if callable(key):
        return normalize(key(frame), frame)
    if isinstance(tuple, key):
        row, col = key
        return normalize(row, frame), normalize(col, frame)
    return key

Installed Versions

INSTALLED VERSIONS

commit : 37ea63d
python : 3.11.3.final.0
python-bits : 64
OS : Linux
OS-release : 5.19.0-43-generic
Version : #44~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon May 22 13:39:36 UTC 2
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_GB.UTF-8
LOCALE : en_GB.UTF-8

pandas : 2.0.1
numpy : 1.24.3
pytz : 2023.3
dateutil : 2.8.2
setuptools : 67.7.2
pip : 23.1.2
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : 8.13.2
pandas_datareader: None
bs4 : None
bottleneck : None
brotli : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
snappy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2023.3
qtpy : None
pyqt5 : None

[topper-123]

The underlying issue is that df.iloc[(1, 0)] is synomous with df.iloc[1, 0], i.e. it's not possible to distinguish between the two. So your first example look alright (but df.iloc[1, 0] is better code).

Your second example some_rows = df.iloc[lambda df: (1, 0)] should fail because tuples should fail if the index is not a MultiIndex. OTOH, some_rows = df.iloc[lambda df: [1, 0]] (a list) should work.

So "callables should ... in all cases not be allowed to return tuples for indexing..." is correct. A PR would be welcome.

[wence-]

Your second example some_rows = df.iloc[lambda df: (1, 0)] should fail because tuples should fail if the index is not a MultiIndex. OTOH, some_rows = df.iloc[lambda df: [1, 0]] (a list) should work.

Hold on. That would mean that with callable syntax it is impossible to pull out rows and columns in one go. Or is it rather that tuple-destructuring happens first and then if any entry is a callable it is called to construct a key for that axis. So that if I wanted to achieve the same thing as df.iloc[1, 0] with lambdas, I should do df.iloc[lambda df: 1, lambda df: 0] ?

If so, then callables should be allowed to return tuples (since that enables them to return a singleton index into a multiindex), but the restriction is that the return value is not destructured using the rules for axis-destructuring.
not be allowed to return tuples for iloc indexing (which this bug report is about) since those indices will be invalid. So, I think that one could just let them return and let the next step raise an IndexError as appropriate.

If I understand correctly then, the proposed "correct" evaluation order for a key is:

1. destructure tuple by axis: key => row_key, col_key (if a dataframe; if a series, this should raise IndexingError if there is a tuple with more than one entry)
2. apply callables if existing: row_key => row_key(frame), col_key => col_key(frame) if either is callable
3. apply non-destructuring/non-callable iloc-indexing semantics to the row and column keys separately

From what I observe (when checking for bug overlap, and so forth) I think that the heuristics for desugaring user input to "normalized" keys are ambiguous in the presence of multiindices (for loc, I think they shouldn't be for iloc since multiindices don't exist in the iloc space). But I'd like to understand what the semantics should be for desugared input (and can then update the docs appropriately to describe how the desugaring takes place).

[Part of the reason for trying to understand this is attempting to make cudf's indexing more aligned with pandas]

[wence-]

Your second example some_rows = df.iloc[lambda df: (1, 0)] should fail because tuples should fail if the index is not a MultiIndex.

If one takes this as meaning the same as df.iloc[(1, 0), :], I contend it should always fail because this is iloc, not loc indexing, and iloc doesn't care about the index.

[topper-123]

Yes, I think that sound right. The basic issue is that tuples are ambiguous, i.e. there's no way to differentiate between df.iloc[1, 2] and df.iloc[(1, 2)], so df.iloc[(1, 2)] can not with certainly be the same as df.iloc[[1, 2]].

Longer term (after this has been removed), IMO it would be great if df.iloc[lambda x: (1, 2)] would be equivalent to df.iloc[1, 2].

[wence-]

Yes, I think that sound right. The basic issue is that tuples are ambiguous, i.e. there's no way to differentiate between df.iloc[1, 2] and df.iloc[(1, 2)], so df.iloc[(1, 2)] can not with certainly be the same as df.iloc[[1, 2]].

OK, so that would be a behaviour change from the current code which is:

    @final
    def __getitem__(self, key):
        check_deprecated_indexers(key)
        if type(key) is tuple:
            key = tuple(list(x) if is_iterator(x) else x for x in key)
            key = tuple(com.apply_if_callable(x, self.obj) for x in key)
            if self._is_scalar_access(key):
                return self.obj._get_value(*key, takeable=self._takeable)
            return self._getitem_tuple(key)
        else:
            # we by definition only have the 0th axis
            axis = self.axis or 0

            maybe_callable = com.apply_if_callable(key, self.obj)
            return self._getitem_axis(maybe_callable, axis=axis)

To something like:

    def __getitem__(self, key):
        check_deprecated_indexers(key)
        if not isinstance(key, tuple):
            key = tuple(itertools.chain([key], itertools.repeat(len(self.obj.shape) - 1)))
        ... # old code as before

[topper-123]

Hi @wence, sorry for the late reply.

The solution would be that callables given to iloc can return tuples will be deprecated, i.e. your example some_rows = df.iloc[lambda df: (1, 0)] should emit a deprecation warning and this behavior be removed in v3.0.