Clarify the documentation about what types the __in lookup accepts

[Дилян Палаузов]

Clarify, that [two underscores]in accepts any iterable (e.g. dict.keys())

diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -2520,7 +2520,7 @@ SQL equivalent::
 ``in``
 ~~~~~~
 
-In a given list.
+In a given iterable.
 
 Example::
 

[Tim Graham]

I'm not sure if "iterable" is the best term. For example, a string is iterable but isn't accepted.

[Дилян Палаузов]

String is accepted, at least with Postgresql. E.g. when a column consists of a single letter x = models.Char(max_char=1, default='A') then ...objects.filter(x__in='ABC') is valid.

[Tim Graham]

You're correct, but that generates WHERE x IN (A, B, C) which I don't think is intuitive.

[Дилян Палаузов]

The SQL generated is correct for the case. I find it also intuitive, as this is also what I would have expected.

Back to he original question: are there any reason against clarifying that the _in lookup accepts iterables of any kind, not just lists?

[Tim Graham]

​PR

[GitHub <noreply@…>]

In 5587485d:

Fixed #28765 -- Clarified docs about what types the in lookup accepts.

[Tim Graham <timograham@…>]

In bcaef2c9:

[2.0.x] Fixed #28765 -- Clarified docs about what types the in lookup accepts.

Backport of 5587485d49af8b32ab660854f751a234baa6610b from master