Block strings from being passed to `__in`

[Christian Ledermann]

ORM: [fieldname]in when passed a string iterates over digits of the string

Can be reproduced in a virgin new project with django-admin startproject mysite
Django version 1.11.13, python version 2.7
Databases tested: PostgreSQL and sqlite3

Observed behaviour:

(Pdb) from django.contrib.auth import get_user_model
(Pdb) User = get_user_model()
(Pdb) query = User.objects.filter(id__in='1234567890')
(Pdb) print query.query
SELECT "auth_user"."id", "auth_user"."password", "auth_user"."last_login", "auth_user"."is_superuser", "auth_user"."username", "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email", "auth_user"."is_staff", "auth_user"."is_active", "auth_user"."date_joined" FROM "auth_user" WHERE "auth_user"."id" IN (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)

Expected Behaviour:
An error is raised

[Christian Ledermann]

Also reproduced with python 3.5, django 2.0.6

[Carlton Gibson]

This is expected behaviour. You pass __in an iterable, a string is an iterable. It's not the desired result, I grant you, but it's just Python.

So first, this isn't a Release Blocker. At best it's a bug, of normal severity.

I'm going to class it as a "New Feature" though because you're basically asking to add type checking here, to make sure you pass the right kind of iterable.
(i.e. not a string.)

For that I'm going to say wontfix. I strongly suspect it wouldn't be worth the effort (i.e the added code would be worse than the problem it's guarding against.) It's also quite likely that there are use-cases where being able to pass a string (as an iterable) is the desired behaviour: there will be people somewhere using that.

[Christian Ledermann]

wontfix is fair enough. imho it should be documented though. I try to find the time to add to the documentation

[Christian Ledermann]

​https://github.com/django/django/pull/10049

[Tim Graham <timograham@…>]

In 11bfe3a8:

Refs #29493 -- Doc'd that the QuerySet in lookup accepts a string.

[Tim Graham <timograham@…>]

In d28360aa:

[2.1.x] Refs #29493 -- Doc'd that the QuerySet in lookup accepts a string.

Backport of 11bfe3a83d79c832bd861b6b87f254197fde1659 from master