The Django filter syntax with the double underscores is like fingernails on a chalkboard to me. I find it insane that they didn't just use operator overloading to create a real query expression language.
I can't quite picture how operator overloading would look like, could you give an example?
Instead of this:
self.filter(end__gt=self._midnight(today))
You could write a "Field" class that implements __getattr__ and __gt__ so you could do
self.filter(Field.end > self._midnight(today))
The "Field.end > self._midnight(today)" would evaluate to an object that would just store "my field name is end and my value needs to be larger than xyz".
filter() can then look into its argument list and construct the filter criteria from the passed Field objects instead of the key value pairs as it does now.
self.filter(end__gt=self._midnight(today))
self.filter(end__gt=<some_datetime_object>)
self.filter(Field.end > self._midnight(today))
self.filter(<True/False>) from datetime import datetime
class Filter():
def __init__(self, name):
self.name = name
def __gt__(self, value):
return {
"field": self.name,
"operator": ">",
"value": value
}
class FieldMeta(type):
def __getattr__(cls, name):
return Filter(name)
class Field(metaclass=FieldMeta):
pass
print(Field.end > datetime(2024, 1, 1))
{'field': 'end', 'operator': '>', 'value': datetime.datetime(2024, 1, 1, 0, 0)}
Edit:
You can even make a little adapter to use this with the current filter system if you really want to:
from datetime import datetime
class Filter():
def __init__(self, name):
self.name = name
def __gt__(self, value):
return {
"field": self.name,
"operator": "gt",
"value": value
}
def __lt__(self, value):
return {
"field": self.name,
"operator": "lt",
"value": value
}
def __eq__(self, value):
return {
"field": self.name,
"operator": "eq",
"value": value
}
class FieldMeta(type):
def __getattr__(cls, name):
return Filter(name)
class Field(metaclass=FieldMeta):
pass
def _(*args):
kwargs = {}
for arg in args:
k = arg["field"] + "__" + arg["operator"]
kwargs[k] = arg["value"]
return kwargs
def filter(**kwargs):
for k, v in kwargs.items():
print(f"{k} = {v}")
filter(**_(Field.end > datetime(2024, 1, 1)))
end__gt = 2024-01-01 00:00:00
Also, apparently SQLAlchemy does exactly what I proposed so apparently they are erring in their ways too.
I honestly don’t find it that bad.
And despite my misgivings, it’s really ergonomic.
You don't need to return a boolean. You need to return an object that implements __bool__.
Get it ?
And even then, when you're dealing with objects that are special to expressions, you don't actually even need __bool__ that much
def __gt__(self, value):
return Q(**{ f"{self.name}__gt": value })
self.filter(Field.end > self._midnight(today))
admin/event/?end__gt=2026-07-26T12:00:00
If you mean “would it allow arbitrary queries from normal view code”, then no it would not—not unless you string eval on the backend or something else dangerous.
https://docs.peewee-orm.com/en/latest/peewee/querying.html#f...