test: Add a hypothesis test for __getitem__

[sjdenny]

Compares polars __getitem__ calls with pandas & pyarrow.

What type of PR is this? (check all applicable)

• 💾 Refactor
• ✨ Feature
• 🐛 Bug Fix
• 🔧 Optimization
• 📝 Documentation
• ✅ Test
• 🐳 Other

Related issues

• Related issue #
• Closes test: add hypothesis test for DataFrame.__getitem__ #1008

Checklist

• Code follows style guide (ruff)
• Tests added
• Documented the changes

If you have comments or can explain your changes, please do so below.

Putting this up for initial feedback - there's a bunch of cases which pyarrow doesn't support (documented in the test). Do we want to support these cases, or should be instead tighten the test (on pandas as well) and declare these unsupported for now?

Cases:

• pyarrow: doesn't support negative indexes
• pyarrow: pairs of slices unsupported, e.g. df[0:1, 'a':'b'] (trivial pairs such as df[:, 'a':'b'] where one slice is : are an exception).
• pyarrow: empty edge case, e.g. df[[], "a":] fails.
• pyarrow & pandas: df[..., ::step] is unsupported, ie slice(None, None, <something>)

[MarcoGorelli]

this is awesome, thanks @sjdenny !

looks like there's a failure in the "random versions" CI job (specifically, pandas==2.0.3)

if we can address that, then I think we can merge this can then gradually address the rest

[sjdenny]

Thanks @MarcoGorelli !

looks like there's a failure in the "random versions" CI job (specifically, pandas==2.0.3)

Looks like this was a flake instead (at least, I was able to reproduce on pandas==2.2.3 too, by running through more examples). I've bumped the number of samples up to 10k in db69469: this does (did) reliably find the failing case, but the downside is it's a bit of a slow test now. Which end of the tradeoff scale do you want to go for? Related to this, I saw Hypothesis has settings profiles, which look neat for supporting faster settings locally & more thorough sampling in CI.

[sjdenny]

Ah, coverage now. Looking 👀

[MarcoGorelli]

awesome stuff, thanks!

there's a couple of really minor things i wanted to address, but i'll try to get this in shortly, really appreciate your contribution here 🙏

[MarcoGorelli]

thanks @sjdenny !

again, so sorry I was really slow with this one - this is really valuable work you've done here, well done 🙌