#32840: Micro-optimisation possibility in Field.get_col
-------------------------------------+-------------------------------------
Reporter: Keryn Knight | Owner: Keryn
Type: | Knight
Cleanup/optimization | Status: assigned
Component: Database layer | Version: dev
(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 Keryn Knight):
* has_patch: 0 => 1
Comment:
PR is here: https://github.com/django/django/pull/14585
For consistency across 2 separate comment areas:
The reason I've not opted for the suggested alternative above (and have
instead kept my rough original proposal) is not a criticism of it, but for
keeping intent as clear as possible -- the version which was suggested
relies on the mental parsing of the `x or y` twice (which always causes
''me'' to double take) and leaves open an accidental regression in the
future should someone justify an implementation of `Field.__bool__` which
is equally/more costly as `Field.__eq__` (I think).
(Obviously I can change that stance, if it's even deemed worthwhile doing
it. We'll see)
--
Ticket URL: <https://code.djangoproject.com/ticket/32840#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.a746fc80a92213ef975c7eb97ecf2197%40djangoproject.com.
