BUG (string): Series.str.slice with negative step

[jbrockmendel]

• closes API/BUG: obj.str.slice(start:None:-1) #59710 (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

[jorisvandenbossche]

See my comment in #59710, but so probably this should be start = -1 if step < 0, and then the above fallback might not be needed

[jorisvandenbossche]

If something fails for older version of pyarrow, can we instead fallback to the python implementation for that version of pyarrow? (instead of failing for the user, i.e. skipping that in the tests)

[jorisvandenbossche]

And while we are touching those methods, move it to the mixin at once as well?

[jbrockmendel]

If something fails for older version of pyarrow, can we instead fallback to the python implementation for that version of pyarrow? (instead of failing for the user, i.e. skipping that in the tests)

just tried that and it broke the min versions test, looks like it is getting an int64 dtype somehow. just restored the xfail.

[jorisvandenbossche]

Sorry, I don't understand how that can let those tests fail to use our long-used object dtype implementation. What was the error you got?
FWIW it would help in reviewing if you pushed additional commits instead of reverting/force pushing, then it is clearer what you actually tried and what the CI said

[jbrockmendel]

Sorry, I don't understand how that can let those tests fail to use our long-used object dtype implementation. What was the error you got?

will re-restore the fallback to find out.

FWIW it would help in reviewing if you pushed additional commits instead of reverting/force pushing, then it is clearer what you actually tried and what the CI said

ive been rebasing (instead of merging main like usual) on the theory it would make backporting easier. if that theory is mistaken, ill go back to the usual system.

[jorisvandenbossche]

ive been rebasing (instead of merging main like usual)

Also when you add new commits for any change you make, you can still use rebase instead of merge to update with the latest main, if you prefer that

on the theory it would make backporting easier.

PRs are always squashed into a single commit on top of main when merging, so I don't think this has any impact on backporting ease

[jorisvandenbossche]

Just pushed one small additional case that wasn't covered yet (one that was failing before with StringDtype as well)

[jorisvandenbossche]

Thanks!