[Django] #35750: Separate method for values_list(..., flat=True), deprecate that kwarg

[Django]

#35750: Separate method for values_list(..., flat=True), deprecate that kwarg
-------------------------------------+-------------------------------------
Reporter: ivan-klass | Type:
| Cleanup/optimization
Status: new | Component: Database
| layer (models, ORM)
Version: 5.1 | Severity: Normal
Keywords: values_list flat | Triage Stage:
flag QuerySet ValuesQuerySet | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
The `flat=True` behavior changes the meaning and signature of the method
completely.

It's an obvious example of the
[https://martinfowler.com/bliki/FlagArgument.html "flag argument"]
antipattern (more [https://luzkan.github.io/smells/flag-argument python
examples])

especially because both input and output types are changed by that flag.
The flag dispatches between two different type signatures.

- with `flat=False` the 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=True` the **result is a flat iterable** with an element type
of the requested field. Keyword **righthand side is usually `True`
literal**, I can't imagine code where `flat=<variable>` in practice.

Given that, it seems like there should be separate methods:

- values_list(*names)

- flat_values_list(name)
--
Ticket URL: <https://code.djangoproject.com/ticket/35750>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#35750: Separate method for values_list(..., flat=True), deprecate that kwarg
-------------------------------------+-------------------------------------

Reporter: ivan-klass | Owner: (none)
Type: | Status: closed
Cleanup/optimization |
Component: Database layer | Version: 5.1
(models, ORM) |
Severity: Normal | Resolution: wontfix

Keywords: values_list flat | Triage Stage:
flag QuerySet ValuesQuerySet | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Sarah Boyce):

* resolution: => wontfix
* status: new => closed

Comment:

Hi ivan, as your requesting for a depreciation, you need to first discuss
this with the wider community and gain strong agreement that this is the
right way forward here.
You can do that by suggesting this on the
[https://forum.djangoproject.com/c/internals/5 Django Forum].
For more information, please refer to
[https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
features/#requesting-features the documented guidelines for requesting
features/api changes].

As `flat=True` is 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/35750#comment:1>