Vivek1106-04 opened a new pull request, #57504: URL: https://github.com/apache/spark/pull/57504
### What changes were proposed in this pull request? Removes an early-return in `LocIndexerLike.__setitem__` (`python/pyspark/pandas/indexing.py`) that, under pandas 3, turned a scalar `.loc` assignment into a no-op when the target columns were passed in a different order than the frame's internal column order. ### Why are the changes needed? The branch (added in SPARK-55296) assumed pandas 3 does not apply such writes. It does, e.g. `df.loc[["viper", "sidewinder"], ["shield", "max_speed"]] = 10` sets both columns. The guard silently dropped valid writes, failing `test_frame_loc_setitem` (`op1`) on pandas 3. For a scalar assignment the column order is irrelevant, and the CoW view-decoupling the branch was meant to protect is already handled by the normal assignment path. ### Does this PR introduce _any_ user-facing change? Yes. With pandas 3, `DataFrame.loc[rows, cols] = scalar` now correctly applies when `cols` is a list in non-internal order; previously it was a silent no-op. No change on pandas 2 (the removed code was behind a `pandas >= 3.0.0` check). ### How was this patch tested? Ran `pyspark.pandas.tests.indexes.test_indexing_loc` (classic and Connect parity) on pandas 3.0.5. The previously failing `test_frame_loc_setitem` passes, and the full `indexes` suite is green with no regressions. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
