feat: allow `Table.filter()` with no args, make it a noop about ibis HOT 4 CLOSED

This seems like a footgun, since any mistakes in filter specification that result in empty arguments (like an incorrect list comprehension) will silently pass through and appear to have no effect.

We'd also want to make this behavior consistent throughout our APIs if we did do it.

For example order_by must be called with at least one key, do we now want to allow that to do nothing if no keys are passed. What about mutate, should that also be no-op with nothing passed? select? What about drop_null/fill_null, rename, relocate? All of these need thinking through for such a change.

It's not as convenient for your particular case, but as the application/library developer you're the only person that knows whether an empty filter is reasonable thing to pass into Ibis from your API.

from ibis.

I'm going to close this out as unplanned.
That said, @NickCrews your anywidget thing looks awesome!

from ibis.

I didn't do the "if not filters" and then I accidentally passed in no filters and I got an error.

Not necessarily fun, but much better to get a loud error than a silent one.

from ibis.

Hmmm good point, we would need to change all the other APIs too. I could be convinced that all those changes are good too. I think they're solvable, but this is definitely not a huge pain so let's leave for now.

To play devils advocate for a moment though: I footgunned myself with the inverse: In my application code, at first I didn't do the "if not filters" and then I accidentally passed in no filters and I got an error. So both choices lead to footguns, just ones of different characteristics. I think I agree your example footgun is more likely than mine though.

from ibis.