Template variable evaluation for True/False ?
du...@habmalnefrage.de
why was False/True evaluation in http://code.djangoproject.com/changeset/3680 reverted?
The committer russelm said: Template variable evalution should follow Python norms.
What would be more Python norms for true and false as True and False ?
Regards,
Dirk
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
James Bennett
> The committer russelm said: Template variable evalution should follow Python norms.
As I understand it, the distinction is between the string 'False' and
the boolean False.
In other words, if you pop open a Python shell and do this:
>>> 'False' is False
False
You find that they're not the same -- 'False' is a non-empty string of
characters and in boolean comparisons evaluates True. False (without
quotes) is a constant which always evaluates False.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
du...@habmalnefrage.de
James Bennett schrieb:
> On 8/30/06, du...@habmalnefrage.de <du...@habmalnefrage.de> wrote:
>> The committer russelm said: Template variable evalution should follow Python norms.
>
> As I understand it, the distinction is between the string 'False' and
> the boolean False.
>
> In other words, if you pop open a Python shell and do this:
>
>>>> 'False' is False
> False
>
> You find that they're not the same -- 'False' is a non-empty string of
> characters and in boolean comparisons evaluates True. False (without
> quotes) is a constant which always evaluates False.
>
I would agree if you take 'False' as a real string which shouldn't evaluate to False, but I had the following templatetag called:
{% mytag "some string" False %}
Which now resolved in an error:
Traceback (most recent call last):
File "/usr/local/lib/python2.4/site-packages/django/template/__init__.py" in render_node
702. result = node.render(context)
File "/usr/local/lib/python2.4/site-packages/django/template/__init__.py" in render
830. resolved_vars = [resolve_variable(var, context) for var in self.vars_to_resolve]
File "/usr/local/lib/python2.4/site-packages/django/template/__init__.py" in resolve_variable
653. raise VariableDoesNotExist, "Failed lookup for key [%s] in %r" % (bits[0], current) # missing attribute
VariableDoesNotExist at /ais/quittung/user/list/
Failed lookup for key [False] in
As I read the code the ' or " signs are remove later in the code and return the resulting string. So 'False' would return the String False and False could not be resolved and won't return String False.
I thing that it is a bug. And the changeset should be re-reverted to fix this. In the other way with context_processors defining global variables False and True variables this can be solved :)
Regards,
Dirk
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit!
"Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl
Tom Tobin
>
> I would agree if you take 'False' as a real string which shouldn't evaluate to False, but I had the following templatetag called:
>
> {% mytag "some string" False %}
>
> Which now resolved in an error:
I'm wondering why you need to pass the literal value False into a
templatetag in the first place; if you're testing whether something
evaluates to boolean True or False, why can't you handle that inside
the tag's logic? Or if you *really* needed to pass either, why can't
you handle the conversion from some pre-defined string (e.g., 'T' or
'True' or whatnot) in said logic?
Russell Keith-Magee
On 8/30/06, du...@habmalnefrage.de < du...@habmalnefrage.de> wrote:
> The committer russelm said: Template variable evalution should follow Python norms.
As I understand it, the distinction is between the string 'False' and
the boolean False.
This is correct.
At render time, templates are provided Python values from a context, where logical operations can be performed on them. 'False' == True in python, so this should be reflected in the logical processing of the template.
Russ Magee %-)
du...@habmalnefrage.de
the usecase for the False/True template evaluation comes from this templatetag here: http://svn.sourceforge.net/viewvc/django-userlibs/trunk/libs.common/src/common/templatetags/commonmedia.py?revision=22&view=markup
function yes_no_icon_url(boolean_value)
Normally the boolean_value comes from an other object which will be evaluated fine by the current template handling.
But then I have exactly one usecase where I don't call the function with an object variable, instead I call it with explicit False and True. I could also call it with 1 or 0 which would be my next step.
But {% any_tag False %} will still handled different than [% any_tag 'False' %}. The first one will result in an error if False is not a variable-name in the RequestContext and the second will use the string 'False'.
Malcolm Tredinnick
I know I"m late to the party here, but I"m just catching up on a couple
of weeks of backlog and can explain what's happening here (and why it's
not a bug):
When the template tag parsing occurs, it looks for things in quotes --
and they are treated as strings -- and things not in quotes, which are
treated as variables to be resolved from the current context. So this
code is looking for a template variable called "False". You want to
introduce a third behaviour which seems to be something along the lines
of "if it's a possible Python constant, treat it as such". That rapidly
gets too confusing.
The current behaviour cannot really be viewed as a bug: you get to pass
in strings and context variables. That is enough to work with; if you
want some easier shortcut for other things, you are going to need to
propose a really good syntax and differentiation scheme.
Regards,
Malcolm