The main advantages I find this has are that filter is just expressed with keyword arguments
I don’t use Django (and vary little Python) so I had to look this up, but the “advantage” you’re referring to kind of goes down the toilet once you need anything other than the default “equals” operator, IMO.
This is the first example I found from the Django docs, for the filter method:
Entry.objects.filter(pub_date_year=2006)
Oh wait, no sorry it was actually this:
Entry.objects.filter(pub_date__year=2006)
Which kind of demonstrates my point. The two are not particularly distinctive visually, but they are obviously very different in terms of the SQL that is generated.
Using variadic arguments to define the column of a predicate is interesting, but the part where you chain together a bunch of double underscores and append them to the column name, honestly sounds like the kind of weird shit Wordpress or some other early-2000’s PHP monstrosity would do (and I say that as someone who makes a significant amount of my income from PHP-related projects).
I don’t use Django (and vary little Python) so I had to look this up, but the “advantage” you’re referring to kind of goes down the toilet once you need anything other than the default “equals” operator, IMO.
This is the first example I found from the Django docs, for the
filtermethod:Entry.objects.filter(pub_date_year=2006)Oh wait, no sorry it was actually this:
Entry.objects.filter(pub_date__year=2006)Which kind of demonstrates my point. The two are not particularly distinctive visually, but they are obviously very different in terms of the SQL that is generated.
Using variadic arguments to define the column of a predicate is interesting, but the part where you chain together a bunch of double underscores and append them to the column name, honestly sounds like the kind of weird shit Wordpress or some other early-2000’s PHP monstrosity would do (and I say that as someone who makes a significant amount of my income from PHP-related projects).
score 1 · canonical