Code

Opened 3 years ago

Closed 3 years ago

#15756 closed Bug (invalid)

Template regression with property lookups

Reported by: Keryn Knight <keryn@…> Owned by: nobody
Component: Template system Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Whilst upgrading from 1.2.5 to 1.3, a colleague discovered a somewhat weird and problematic variable lookup issue in the template system. I've attempted to compress it down into a replicable test. I've tested this on Windows and Mac, both running Python 2.6 and Django 1.2.5 & 1.3

from django.template import Context, Template

class A(object):
    name = 'A'
    def __init__(self, anything):
        ''' this is the crux of the problem? '''
        pass

class B(A):
    name = u'B'


class C(B):
    name = u'C'

out = Template('{% for c in class_list %}{{ c.name }}{% endfor %}')

# this works under 1.2.5, but not 1.3
fail_list = (A, B, C)
# this works under both.
pass_list = (A(1), B(2), C(3))

# using classes; expected historic output u'ABC', in 1.3 returns u''
out.render(Context({'class_list': fail_list}))
# using instantiated objects, always returns u'ABC'
out.render(Context({'class_list': pass_list}))

Interestingly, if the init method of the class doesn't take additional parameters (ie: remove the anything kwarg), it seems to be fine. I have absolutely no clue about the inner workings of the template compiler, but I'm presuming it does some sort of clever variable resolution that's changed in this edge case.

Symptomatic of my ignorance of the templating voodoo is that I don't really know how to summarise the problem, so the title may be better expressed, and I may have missed pre-existing tickets for the same thing.

Attachments (0)

Change History (1)

comment:1 Changed 3 years ago by lrekucki

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

This is actually a fix of previous inconsistent behaviour. See Django 1.3 release notes: http://docs.djangoproject.com/en/dev/releases/1.3/#callables-in-templates

PS. A similar "problem" involving classes was reported in #15660.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.