[Django] #34104: Making Q.__eq__ work regardless of ordering

2 views
Skip to first unread message

Django

unread,
Oct 17, 2022, 6:28:10 PM10/17/22
to django-...@googlegroups.com
#34104: Making Q.__eq__ work regardless of ordering
-------------------------------------+-------------------------------------
Reporter: Daniel | Owner: nobody
Wysocki |
Type: | Status: new
Uncategorized |
Component: Database | Version: 4.1
layer (models, ORM) |
Severity: Normal | Keywords: query
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
The `Q.__eq__` method does not recognize the associativity/commutativity
of connector operators. For instance

{{{
#!python
(Q(id=1) | Q(id=2)) == (Q(id=2) | Q(id=1))
}}}

evaluates to `False`.

A possible solution: add an attribute to `django.utils.tree.Node` to flag
it as associative/commutative (maybe call it `unordered`). If that flag
is set, cast `self.children` and `other.children` to sets instead of lists
before comparing them.

--
Ticket URL: <https://code.djangoproject.com/ticket/34104>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Oct 17, 2022, 6:28:47 PM10/17/22
to django-...@googlegroups.com
#34104: Making Q.__eq__ work regardless of ordering
-------------------------------------+-------------------------------------
Reporter: Daniel Wysocki | Owner: nobody
Type: Uncategorized | Status: new
Component: Database layer | Version: 4.1
(models, ORM) |
Severity: Normal | Resolution:
Keywords: query | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Daniel Wysocki:

Old description:

> The `Q.__eq__` method does not recognize the associativity/commutativity
> of connector operators. For instance
>
> {{{
> #!python
> (Q(id=1) | Q(id=2)) == (Q(id=2) | Q(id=1))
> }}}
>
> evaluates to `False`.
>
> A possible solution: add an attribute to `django.utils.tree.Node` to flag
> it as associative/commutative (maybe call it `unordered`). If that flag
> is set, cast `self.children` and `other.children` to sets instead of
> lists before comparing them.

New description:

The `Q.__eq__` method does not recognize the associativity/commutativity
of connector operators. For instance

{{{
#!python
(Q(id=1) | Q(id=2)) == (Q(id=2) | Q(id=1))
}}}

evaluates to `False`, despite the queries being equivalent.

A possible solution: add an attribute to `django.utils.tree.Node` to flag
it as associative/commutative (maybe call it `unordered`). If that flag
is set, cast `self.children` and `other.children` to sets instead of lists
before comparing them.

--

--
Ticket URL: <https://code.djangoproject.com/ticket/34104#comment:1>

Django

unread,
Oct 18, 2022, 3:32:12 PM10/18/22
to django-...@googlegroups.com
#34104: Making Q.__eq__ work regardless of ordering
-------------------------------------+-------------------------------------
Reporter: Daniel Wysocki | Owner: nobody
Type: New feature | Status: closed

Component: Database layer | Version: 4.1
(models, ORM) |
Severity: Normal | Resolution: needsinfo

Keywords: query | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):

* status: new => closed
* type: Uncategorized => New feature
* resolution: => needsinfo


Comment:

Thanks for the report. The main question is: why do you need to change the
current behavior? Is it problematic for Django itself? Please provide a
rationale.

--
Ticket URL: <https://code.djangoproject.com/ticket/34104#comment:2>

Reply all
Reply to author
Forward
0 new messages