Wrap the Filter interface

[jmao-denver]

Fixes #2335

[devinrsmith]

Is this more pythonic, or is my_filter.not()? The java interface has not() as part of the interface.

[jmao-denver]

'not' is a Python keyword, can't be used as an identifier

[devinrsmith]

We could do my_filter.not_() (we wouldn't need to provide it in java since we can do it in the wrapper) if desired.

[devinrsmith]

Or, as property: my_filter.not_

[devinrsmith]

Looking at this, and unit tests, it looks like we have:

my_table.where(or_(Filter.from_(["a > 100", "b < 1000", "c < 0"])))

I'm wondering if we don't want something like:

my_table.where(or_(["a > 100", "b < 1000", "c < 0"]))

And, it might not just be strings, but filters themselves:

f1 = and_(["a > 100", "b <1000"])
f2 = and_(["c > 1", "d < 1"])
f = or_([f1, f2, "z>42"])
my_table.where(f)

[jmao-denver]

Not sure we want to allow mixing Filter objects with conditional strings. Arguably it might be more confusing than helpful.

[devinrsmith]

I'm fine w/ the conclusion as long as we are happy.

f1 = and_(Filter.from_(["a > 100", "b <1000"]))
f2 = and_(Filter.from_(["c > 1", "d < 1"]))
f = or_([f1, f2, Filter.from_("z>42")])
my_table.where(f)

[devinrsmith]

I'm "ok" w/ as-is; unless we think there are usability concerns wrt creating filters.