Hi,
At present, all Django DB query functions accept and use kwargs to
construct queries. All top level kwargs queries are then AND'ed
together.
Given that the (relatively) new Q() syntax for query construction
doesn't require the top level kwarg, doesn't it make sense to allow
unnamed *opts parameters as well as **kwargs in query functions? That
is, allow Q() objects to be provided as unnamed parameters to
get_object, etc, where they are ANDed together in addition to any
kwargs that are provided.
If this were done, the existing syntax:
polls.get_object(
complex=
(Q(question__startswith='Who') &
(Q(pub_date__exact=date(2005, 5, 2)) |
Q(pub_date__exact=date(2005, 5, 6)))
)
could be rephrased as:
polls.get_object(
Q(question__startswith='Who'),
Q(pub_date__exact=date(2005, 5, 2)) | Q(pub_date__exact=date(2005,
5, 6))
)
To maintain backwards compatibility, the existing complex kwarg could
be retained, so the first example would remain legal.
A type error would be thrown if a non-Q object was provided as an
option (or, for an even more Pythonic solution, check for existence of
a get_sql method on the provided parameter rather than isinstance(opt,
Q)).
Admittedly, this would mean that opts elements would need to preceed
kwargs queries. However, I would think that this issue could be managed
with adequate documentation in the discussion of Q() queries.
Thanks,
Russ Magee
