#35750 closed Cleanup/optimization (wontfix)
Separate method for values_list(..., flat=True), deprecate that kwarg
| Reported by: | ivan-klass | Owned by: | |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | 5.1 |
| Severity: | Normal | Keywords: | values_list flat flag QuerySet ValuesQuerySet |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | yes | UI/UX: | no |
Description
The flat=True behavior changes the meaning and signature of the method completely.
It's an obvious example of the flag argument antipattern (more python examples)
especially because both input and output types are changed by that flag. The flag dispatches between two different type signatures.
- with
flat=Falsethe returning value is an iterable of tuples. Input is a var args of names corresponding to the size of the tuple. The flag value is usually never provided as a keyword assuming the default.
- with
flat=Truethe result is a flat iterable with an element type of the requested field. Keyword righthand side is usuallyTrueliteral, I can't imagine code whereflat=<variable>in practice.
Given that, it seems like there should be separate methods:
- values_list(*names)
- flat_values_list(name)
Note:
See TracTickets
for help on using tickets.
Hi ivan, as you're requesting a depreciation, you must first discuss this with the wider community and gain strong agreement that this is the right way forward.
You can do that by suggesting this on the Django Forum.
For more information, please refer to the documented guidelines for requesting features/api changes.
As
flat=Trueis a well-used feature of Django, I think it is unlikely it will be depreciated. The upgrade burden would be greater than the benefit IMO.However, if the community agrees with the proposal, feel free to come back and reopen the ticket with a link to the discussion.