[Django] #32134: Upgrading 2.2>3.0 causes named tuples used as arguments to __range to error.
Django
error.
------------------------------------------+------------------------
Reporter: Gordon Wrigley | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 3.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------+------------------------
I noticed this while upgrading a project from 2.2 to 3.0.
This project passes named 2-tuples as arguments to __range queryset
filters. This works fine on 2.2. On 3.0 it causes the following error:
`TypeError: __new__() missing 1 required positional argument: 'far'`.
This happens because django.db.models.sql.query.Query.resolve_lookup_value
goes into the tuple elements to resolve lookups and then attempts to
reconstitute the tuple with the resolved elements.
When it attempts to construct the new tuple it preserves the type (the
named tuple) but it passes a iterator to it's constructor.
NamedTuples don't have the code path for copying an iterator, and so it
errors on insufficient arguments.
The fix is to * expand the contents of the iterator into the constructor.
--
Ticket URL: <https://code.djangoproject.com/ticket/32134>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
error.
Reporter: Gordon Wrigley | Owner: Adam
| (Chainz) Johnson
Type: Bug | Status: assigned
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Adam (Chainz) Johnson):
* status: new => assigned
* cc: Adam (Chainz) Johnson (added)
* component: Uncategorized => Database layer (models, ORM)
* owner: nobody => Adam (Chainz) Johnson
* has_patch: 0 => 1
* type: Uncategorized => Bug
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/32134#comment:1>
Django
error.
Reporter: Gordon Wrigley | Owner: Adam
| (Chainz) Johnson
Type: Bug | Status: assigned
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* needs_better_patch: 0 => 1
* version: 3.0 => 3.1
* severity: Normal => Release blocker
Comment:
It works in Django 3.0, as far as I'm aware it's a regression in Django
3.1, see 8be79984dce7d819879a6e594ca69c5f95a08378.
Marking as "needs improvement" because the patch breaks the original fix,
see #30687.
--
Ticket URL: <https://code.djangoproject.com/ticket/32134#comment:2>
Django
error.
Reporter: Gordon Wrigley | Owner: Adam
| (Chainz) Johnson
Type: Bug | Status: assigned
Component: Database layer | Version: 3.1
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Comment (by Gordon Wrigley):
I definitely experience the problem on 3.0.10
--
Ticket URL: <https://code.djangoproject.com/ticket/32134#comment:3>
Django
error.
Reporter: Gordon Wrigley | Owner: Adam
| (Chainz) Johnson
Type: Bug | Status: assigned
(models, ORM) |
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* version: 3.1 => 3.0
* severity: Release blocker => Normal
Comment:
After double-checking, it's a regression introduced in Django 3.0
(fa6076daf460df2c2c5ff9f62862f050bc4427f4) when we backported
8be79984dce7d819879a6e594ca69c5f95a08378. Therefore it doesn't qualify for
a backport.
--
Ticket URL: <https://code.djangoproject.com/ticket/32134#comment:4>
Django
error.
Reporter: Gordon Wrigley | Owner: Adam
| (Chainz) Johnson
Type: Bug | Status: assigned
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution:
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* needs_better_patch: 1 => 0
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/32134#comment:5>
Django
error.
Reporter: Gordon Wrigley | Owner: Adam
| (Chainz) Johnson
Component: Database layer | Version: 3.0
(models, ORM) |
Keywords: | Triage Stage: Ready for
| checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak <felisiak.mariusz@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"a56586eafeb6d1212bc291d1a2e7d33c87edbc33" a56586ea]:
{{{
#!CommitTicketReference repository=""
revision="a56586eafeb6d1212bc291d1a2e7d33c87edbc33"
Fixed #32134 -- Fixed crash of __range lookup with namedtuple.
Regression in 8be79984dce7d819879a6e594ca69c5f95a08378.
Thanks Gordon Wrigley for the report.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/32134#comment:6>
Django
error.
Reporter: Gordon Wrigley | Owner: Adam
| (Chainz) Johnson
Type: Bug | Status: closed
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Gordon Wrigley):
It seems weird to me that named tuples would work in latest 2.2 and latest
3.1 but not latest 3.0. That sounds like a regression bug in the 3.0 line.
For me personally it not being backported is somewhat inconvenient. Due to
3rd party lib issues this project can't go straight to 3.1, but I can work
around
the lack of backport by overriding the __new__ methods on the named
tuples.
--
Ticket URL: <https://code.djangoproject.com/ticket/32134#comment:7>
Django
error.
Reporter: Gordon Wrigley | Owner: Adam
| (Chainz) Johnson
Type: Bug | Status: closed
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Mariusz Felisiak):
Replying to [comment:7 Gordon Wrigley]:
> It seems weird to me that named tuples would work in latest 2.2 and
latest 3.1 but not latest 3.0. That sounds like a regression bug in the
3.0 line.
> For me personally it not being backported is somewhat inconvenient. Due
to 3rd party lib issues this project can't go straight to 3.1, but I can
work around
> the lack of backport by overriding the __new__ methods on the named
tuples.
It will not be backported to Django 3.1. It was introduced in Django 3.0,
but reported after the Django 3.1 release. Per our backporting policy this
means it doesn't qualify for a backport to 3.0.x or 3.1.x anymore. See
[https://docs.djangoproject.com/en/3.0/internals/release-process/ Django’s
release process] for more details.
> "Regressions from older versions of Django introduced in the current
release series."
Moreover, Django 3.0 is in extended support so it doesn't receive bugfixes
anymore (except security patches).
--
Ticket URL: <https://code.djangoproject.com/ticket/32134#comment:8>
Django
error.
Reporter: Gordon Wrigley | Owner: Adam
| (Chainz) Johnson
Type: Bug | Status: closed
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Claude Paroz):
Gordon, you might write to the django-developers mailing list, maybe you
can get some support to amend the backport policy in case of regressions.
It also looks weird to me that we backport *regressions* to versions n and
n-2, but not n-1.
--
Ticket URL: <https://code.djangoproject.com/ticket/32134#comment:9>
Django
error.
Reporter: Gordon Wrigley | Owner: Adam
| (Chainz) Johnson
Type: Bug | Status: closed
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Mariusz Felisiak):
Replying to [comment:9 Claude Paroz]:
> Gordon, you might write to the django-developers mailing list, maybe you
can get some support to amend the backport policy in case of regressions.
It also looks weird to me that we backport *regressions* to versions n and
n-2, but not n-1.
I'm not sure if I understand, we didn't backport this fix to any stable
branch. Also, using `namedtuple` with the `__range` lookup wasn't tested
or documented.
--
Ticket URL: <https://code.djangoproject.com/ticket/32134#comment:10>
Django
error.
Reporter: Gordon Wrigley | Owner: Adam
| (Chainz) Johnson
Type: Bug | Status: closed
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Claude Paroz):
Oh sorry Mariusz, I was wrong about the backport claim. I'm still a bit
uneased by this strict backport policy for regressions, but this was
already discussed and there is nothing new here.
--
Ticket URL: <https://code.djangoproject.com/ticket/32134#comment:11>