| ▲ | 7bit 2 hours ago | ||||||||||||||||
There may be many reason other than rejecting that suggestion leading to what it is know. Your statement somehow suggests that it was deliberately decided against what you propose. I don't think we know that. I can't quite picture how operator overloading would look like, could you give an example? | |||||||||||||||||
| ▲ | echoangle an hour ago | parent [-] | ||||||||||||||||
> 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. | |||||||||||||||||
| |||||||||||||||||