#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 django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.a746fc80a92213ef975c7eb97ecf2197%40djangoproject.com.
