Opened 12 years ago

Closed 4 years ago

Last modified 4 years ago

#20423 closed Cleanup/optimization (fixed)

Template renderer does not parse numeric variables

Reported by: antonio@… Owned by: Tim McCurrach
Component: Documentation Version: dev
Severity: Normal Keywords: number variable
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Currently a Variable is defined, according to the django template manual, as :

Variable names consist of any combination of alphanumeric characters and the underscore ("_").

If a variable is composed of numbers only, it will not get its context data correctly, coming across as an int. This patch assigns the appropriate context data to the Variable class when it encounters an integer.

Here's the current behavior:

from django.template.base import Template
from django.template.base import Context
t = Template("{{ 123 }}")
t.render(Context())

u'123'

t = Template("{{ foo }}")
t.render(Context({"foo":"bar"}))

u'bar'

Attachments (1)

number_templating.diff (515 bytes ) - added by antonio@… 12 years ago.
Patch to assign context to numeric Variables in Django templating

Download all attachments as: .zip

Change History (15)

by antonio@…, 12 years ago

Attachment: number_templating.diff added

Patch to assign context to numeric Variables in Django templating

comment:1 by anonymous, 12 years ago

Definitely not full fix, it does cause regressions elsewhere - namely the view loading a changelist in the Admin.

comment:2 by Simon Charette, 12 years ago

The issue is valid but IMHO the code should be fixed to disallow such uses of number variables and the documentation fixed accordingly (e.g Variable name can't start with an integer).

I know this might be backward incompatible but I can't see any valid use case for this behavior, looks more like a side effect/oversight of the access by index feature. Am I missing something here?

comment:3 by Simon Charette, 12 years ago

Patch needs improvement: set
Triage Stage: UnreviewedAccepted

comment:4 by Deepak, 12 years ago

Owner: changed from nobody to Deepak
Status: newassigned

comment:5 by Deepak, 11 years ago

I totally agree with charettes that there may not be an use case for this. Hence, I'd propose to add warning first and then raise an exceptions if integer or float variable names are used. Does it makes sense?

comment:6 by anonymous, 11 years ago

Makes more sense as a doc ticket, agreed! Thanks for looking!

Antonio

comment:7 by Mariusz Felisiak, 4 years ago

Has patch: unset
Owner: Deepak removed
Patch needs improvement: unset
Status: assignednew

comment:8 by Tim McCurrach, 4 years ago

Owner: set to Tim McCurrach
Status: newassigned

I have created a PR to update the docs. Given it will now be documented, adding in any checks or warnings seems like overkill to me.

comment:9 by Jacob Walls, 4 years ago

Has patch: set

comment:10 by Jacob Walls, 4 years ago

Component: Template systemDocumentation
Type: BugCleanup/optimization

comment:11 by Mariusz Felisiak, 4 years ago

Patch needs improvement: set

comment:12 by GitHub <noreply@…>, 4 years ago

Resolution: fixed
Status: assignedclosed

In 7587139d:

Fixed #20423 -- Doc'd that DTL variable names may not be a number.

comment:13 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

In 7e6e8221:

[3.2.x] Fixed #20423 -- Doc'd that DTL variable names may not be a number.

Backport of 7587139d35b630a19fdc55a5f3789475e5ed26c8 from master

comment:14 by Mariusz Felisiak, 4 years ago

Patch needs improvement: unset
Note: See TracTickets for help on using tickets.
Back to Top