On Tuesday, 4 December 2012 14:25:22 UTC+10, Russell Keith-Magee wrote:
>
>
> Now, I'll completely grant that the same "private" interpretation doesn't
> apply to dictionary keys in the Python context, but:
>
> 1) From a Django template language perspective, there's no syntactic
> difference between accessing an object attribute and subscripting a
> dictionary, so it would be weird to have different behaviour in the two
> cases.
>
> 2) Having a mechanism for private data can be very useful from a data
> hygiene perspective -- it means you can pass data around the view that you
> want to have private, and know that it's not going to be accidentally
> exposed to the template.
>
I'm not proposing that you do away with the notion of private variables, I
just want to see it consistent with Python as opposed to implementing its
own artificial rules. Granted that Django's templating language is indeed
its own langue but to a developer what the variable part of the language
does is provide access to the underlying Python data structures. The fact
that it doesn't do it in a consistent fashion is a real gottcha. Not
providing access to private variables shouldn't come at the cost of
accessing perfectly legal dictionary items.
> The ticket you reference is really asking a different question -- the
> ability to do dictionary/array subscripting by variable. What the ticket is
> asking for is an analog for the Python code:
>
>b = {'hello': True, 'goodbye': False}
>x = 'hello'
>print b[x]
>
> The reason this has been considered out of scope is that Django's template
> language *isn't* a programming language - by design. As part of enforcing
> that philosophy, certain "obvious" programming mechanisms, such as
> subscripting by variable and passing arguments to functions, have been
> omitted.
>
Sure, I can accept that, and I probably should of been clearer. I think
that proposed solution has the side effect that it makes accessing dict
items with keys that start with _ possible again. It isn't the best
solution to this problem in my eyes but it is at least workable. Right now,
if I want to access these dict items, I have to define my own filter. That
isn't very workable.
What I would prefer to see is that the variable syntax behaves in what I
believe to be a more consistent manner. That is, it tries to access the
underlying data structure by obeying the python rules. Currently, the doc
for the variable syntax says "Technically, when the template system
encounters a dot, it tries the following lookups, in this order: Dictionary
lookup, Attribute lookup, Method call, List-index lookup". When the
template engine encounters something like {{ my_dict._key }}, instead of
just throwing it away because it starts with _, it should perform the only
valid python lookup out of the list of lookups it can, which happens to be
a Dictionary lookup.
This seems like a pretty trivial change but gets rid of a pretty annoying
gottcha which comes about by Django actually trying to adhere to python
standards. In my case, I am trying to access a dict produced by rawes as a
result of a query to ElasticSearch. It is a multi-levelled dict produced
from JSON. Having to either pre-process that JSON data to remove keys that
start with _ or include a new filter just so I can access the data isn't
very nice especially when I can't see any real benefit to
the template language.
Cheers
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/ANJrwtnG25wJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
