#29907 closed New feature (wontfix)
Allow QuerySet.get() and filter() to accept a positional argument for implicit primary key filtering
Reported by: | Antoine | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I'm creating this ticket to see if there is interest to implement positional arguments in queryset filtering.
Current situation
Currently the only way to use positional arguments to filter can be either:
- Passing a single or multiple Q objects:
MyClass.objects.filter(Q(key=value)) MyClass.objects.filter(Q(key=value), Q(other_key=value))
- Passing a couple is also working (not sure if this is a happy accident)
MyClass.objects.filter((key, value))
- Combination of both is also proven to work
MyClass.objects.filter((key, value), Q(other_key=value))
Suggestion
My feature suggestion is to leverage the case when a non-Q / non couple object is passed, so it implicitly interpreted as the value for the model's pk
.
This could ease/simplify code by omitting pk
when this is the only filter used:
MyClass.objects.get(value) # Translates into: MyClass.objects.get(pk=value)
or
MyClass.objects.filter(value) # Translates into: MyClass.objects.filter(pk=value)
or
MyClass.objects.filter(Q(value)) # Translates into: MyClass.objects.filter(Q(pk=value))
Do you think it's worth it? It could be leveraged to simplify many situations.
Change History (3)
comment:1 by , 6 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Summary: | Queryset.get(), Queryset.filter(), and Q() with positional arguments → Allow QuerySet.get() and filter() to accept a positional argument for implicit primary key filtering |
comment:2 by , 6 years ago
Hey there, I've personally wished get(pk)
was supported in the past but as Tim said this should be brought to the mailing list to try to get a consensus.
From The Zen of Python, "Explicit is better than implicit." Proposals for design decisions like this are better made on the DevelopersMailingList but I doubt there would be consensus to do this.