> > there are classes in the Pythoniverse that implement a __getitem__ method > for the sake of syntactical sweetness, but they are no mappings.
My understanding of what ducktyping means is that by implementing __getitem__ such objects are declaring they are mappings. I'm -1 on this change because the scope is very large (potentially breaking millions of lines of templates in the real world) and it's also a fairly subtle difference, which makes it hard to explain to end users. Some of your other suggestions for speeding up template rendering would be worth looking into though, any speed gains would be welcome. As to solving your initial problem, Tim's suggestion on the ticket of wrapping such objects with a class that implements the correct lookup behaviour in templates, is a sensible approach. On 10 November 2017 at 14:40, <[email protected]> wrote: > ciao tutti, > > i've already opened a ticket [1] that elaborates why i consider the > behaviour of the template engines variable lookup as buggy, i'll copy > the description below. > > i also opened a pull request [2] that demonstrates my progress on a > solution so far. > > thanks for any feedback. > > [1]: https://code.djangoproject.com/ticket/28782 > [2]: https://github.com/django/django/pull/9341 > > bug description w/o markup: > > there are classes in the Pythoniverse that implement a __getitem__ > method for the sake of syntactical sweetness, but they are no mappings. > (in my case it's a wrapper around an xml document where __getitem__ > returns the result of xpath evaluations. there are other use-cases > around, but i don't remember any atm.). > this causes a lookup in a template rendering context on an attribute of > such instances to return an unexpected value, because foo[bar] doesn't > necessarily raise an exception and returns some value, while foo.bar was > intended. this is caused by the very implicit implementation of > django.template.base.Variable._resolve_lookup. > my approach to solve this issue is to refactor that method to an > explicit behaviour mainly based on type checks, so a member lookup is > only performed on instances that base on collections.abc.Mapping which > any implementation of a mapping should. my rationale is that the > documentations mentions a dictionary (though mapping would be more > precise term) lookup, not a lookup via __getitem__, and > dictionary/mapping objects should base on the mentioned abstract class > (the why is elaborated in PEP 3119). > beside solving my problem, i would argue that in doubt "explicit is > better than implicit" excels "it's better to ask forgiveness than to ask > permission" and the explicit approach is more comprehensible. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/4c3db0c806233f390acdeb91af836d98%40riseup.net. > For more options, visit https://groups.google.com/d/optout. > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3cMJUqdR9%2BSZvcsJBkbgggA1GQq0Un4Tz09Nij6XSYNA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
