Changes between Initial Version and Version 1 of Ticket #30197, comment 5


Ignore:
Timestamp:
Feb 22, 2019, 6:11:45 PM (5 years ago)
Author:
Alex Epshteyn

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #30197, comment 5

    initial v1  
    1010I agree that this would be a breaking change, but **I don't agree that this is a duplicate of #15791**, because in some cases it may not be possible to set `do_not_call_in_templates` on the callable object (see [https://code.djangoproject.com/ticket/30197#comment:3 my reply to Tim Graham's comment]).
    1111
    12 Furthermore, the existing the `do_not_call_in_templates` workaround requires making changes to objects in the application layer, which **breaks the fundamental [https://django.readthedocs.io/en/stable/misc/design-philosophies.html Django design philosophies]** of //[https://django.readthedocs.io/en/stable/misc/design-philosophies.html#loose-coupling "Loose coupling"]// (by moving some template-specific concerns from the template layer to the application layer), //[https://django.readthedocs.io/en/stable/misc/design-philosophies.html#less-code "Less code"]//, and //[https://django.readthedocs.io/en/stable/misc/design-philosophies.html#explicit-is-better-than-implicit "Explicit is better than implicit"].
     12Furthermore, the existing the `do_not_call_in_templates` workaround requires modifying objects in the application layer, which **breaks the fundamental [https://django.readthedocs.io/en/stable/misc/design-philosophies.html Django design philosophies]** of //[https://django.readthedocs.io/en/stable/misc/design-philosophies.html#loose-coupling "Loose coupling"]// (by moving some template-specific concerns from the template layer to the application layer), //[https://django.readthedocs.io/en/stable/misc/design-philosophies.html#less-code "Less code"]//, and //[https://django.readthedocs.io/en/stable/misc/design-philosophies.html#explicit-is-better-than-implicit "Explicit is better than implicit"].
    1313
    1414Therefore, I would argue that **a breaking change like this is justified**, because it would fix a serious design flaw of the template variable resolution algorithm.  I've been bit by this problem several times, which has caused much frustration and hours wasted on debugging.  And I'm not the only one (as evidenced by the prevalence of tickets opened for this issue).
Back to Top