Changes between Initial Version and Version 1 of Ticket #29745, comment 2
- Timestamp:
- Sep 7, 2018, 3:56:20 PM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #29745, comment 2
initial v1 3 3 This is caused by the fact `models.Field.__eq__` [https://github.com/django/django/blob/570402ffd7efd529eb597d86525b80a6fbfca0e7/django/db/models/fields/__init__.py#L495-L499 is based of creation_counter] which makes `models.IntegerField() != models.IntegerField()` and thus `Cast(expr, models.IntegerField())` != `Cast(expr, models.IntegerField())`. 4 4 5 I feel like this is going to be hard to solve at the `Field` level without revisiting how we determine field definition order ing. This has always been a hack to work around unordered `type.__new__(attrs)` anyway which is not necessary in Python 3.6+ and can be worked around in Python 3.5+ thanks to [https://www.python.org/dev/peps/pep-0520/ PEP 520]'s `type.__prepare__` which could be added to `ModelBase`.5 I feel like this is going to be hard to solve at the `Field` level without revisiting how we determine field definition order. This has always been a hack to work around unordered `type.__new__(attrs)` anyway which is not necessary in Python 3.6+ and can be worked around in Python 3.5+ thanks to [https://www.python.org/dev/peps/pep-0520/ PEP 520]'s `type.__prepare__` which could be added to `ModelBase`. 6 6 7 7 Another solution could be to special case `output_field` equality checks in `BaseExpression.__eq__` [https://github.com/django/django/blob/570402ffd7efd529eb597d86525b80a6fbfca0e7/django/db/models/expressions.py#L371-L374 even more]. This would surely be a less invasive change if we plan to backport the adjustment.