Re: [Django] #36934: BuiltinLookup.as_sql breaks with params-as-a-tuple (was: BuiltinLookup breaks with params-as-a-tuple in django 6.0)

0 views
Skip to first unread message

Django

unread,
Feb 19, 2026, 2:27:08 PMFeb 19
to django-...@googlegroups.com
#36934: BuiltinLookup.as_sql breaks with params-as-a-tuple
-------------------------------------+-------------------------------------
Reporter: Stefan Bühler | Owner: Jacob
| Walls
Type: Bug | Status: assigned
Component: Database layer | Version: 6.0
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Jacob Walls):

* has_patch: 1 => 0
* owner: (none) => Jacob Walls
* status: new => assigned
* summary: BuiltinLookup breaks with params-as-a-tuple in django 6.0 =>
BuiltinLookup.as_sql breaks with params-as-a-tuple

Comment:

Thanks, I was beginning to miss the forest for the trees here.

> Now the linked pull-request not only replaces the broken params.extend
lines but also changes the return type from list to tuple in a few places
- I suppose the latter ones could be omitted in the backport, but
BuiltinLookup.as_sql (and YearLookup.as_sql) really needs to handle tuple
params from process_lhs.

I agree -- we can backport the bit about replacing `extend()` with the
unpacking operator without any risk of regressions. I'll prepare that.
--
Ticket URL: <https://code.djangoproject.com/ticket/36934#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Reply all
Reply to author
Forward
0 new messages