On Wed, 2006-08-30 at 22:58 +0200, [EMAIL PROTECTED] wrote:
> Hi James,
>
> James Bennett schrieb:
> > On 8/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 :)
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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
