Changes between Initial Version and Version 1 of Ticket #29745, comment 2


Ignore:
Timestamp:
Sep 7, 2018, 3:56:20 PM (6 years ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #29745, comment 2

    initial v1  
    33This 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())`.
    44
    5 I feel like this is going to be hard to solve at the `Field` level without revisiting how we determine field definition ordering. 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`.
     5I 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`.
    66
    77Another 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.
Back to Top