OK, folks; time to drop this particular argument. As you can see from
this thread, a consensus here is not forthcoming, and now we're all
just wasting time.
I'd encourange anyone who likes Django templates but wants something
more programmer-oriented to take a look at Jinja (inspired by Django)
o
There must be a lot of us who have created a similar filter. My particular
version looks like this:
from django.template import resolve_variable
def lookup(value, key):
return resolve_variable(key,value)
so that it behaves like the normal attribute access.I use this to do things
like send a lis
On Thu, Mar 6, 2008 at 8:25 PM, Ian Kelly <[EMAIL PROTECTED]> wrote:
> Why do I have a sudden fear that a branch is going to spawn called
> "newtemplates"?
That won't be happening. As Jacob noted eloquently, this
filter/feature isn't something worth adding at this time.
It's quite easy to add
On Thu, Mar 6, 2008 at 7:06 PM, Collin Grady <[EMAIL PROTECTED]> wrote:
> To keep things consistent though, you'd then likely have to change normal
> access
> to work like that as well, so instead of foo.bar to look up the key "bar"
> you'd
> have to change it to use foo["bar"], which would b
Matthew Marshall said the following:
> What's wrong with ``{{ foo[bar] }}`` ?
>
> That's how it's done in python, javascript, php, and others. Most people
> writing html templates will be somewhat familiar with at least Javascript.
To keep things consistent though, you'd then likely have to ch
On Tuesday 04 March 2008 14:54:38 Jacob Kaplan-Moss wrote:
> Second, there's the question of weather this is a first-class
> language-level feature or a filter. If it's the former, there's a
> syntactic decision to be made; some have proposed something like ``{{
> foo.$bar }}``, but anything that
On Fri, Mar 7, 2008 at 8:53 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> I suggest {{ foo->bar }} syntax. It is simple, common to programmers,
> easy to remember and recognize, does not interfere with any other
> features.
-1.
1) The primary audience of the Django template language is desi
I suggest {{ foo->bar }} syntax. It is simple, common to programmers,
easy to remember and recognize, does not interfere with any other
features.
On Wed, Mar 5, 2008 at 5:50 PM, vcc <[EMAIL PROTECTED]> wrote:
>
> I got another ID: foo.(bar)
> It's clear and no conflict, also can use nested, for
Hi all,
Forgive me if this is slightly off topic, but I hope to get some
feedback on the design of what I think is an improved version of the
django-rest-interface. I have posted a gzipped archive of the code and
an example application here:
http://code.google.com/p/django-rest-interface/i
Jeremy Dunck wrote:
> DId this ever get fixed for you? :-/
>
Yep, Jacob helped me out.
John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-d
> Something like that should work though:
>
> try:
> reimported = imported
> raise Exception, "already imported!"
> catch NameError:
> imported = True
>
>
Sorry, if __name__ is different, this won't help, too. The python
interpreter thinks that there are two different modules.
On
11 matches
Mail list logo
