id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 28782,Template variable resolution on objects that are no mappings but implement __getitem__,Frank Sachsenheim,Frank Sachsenheim,"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 [https://docs.python.org/3/glossary.html#term-mapping 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 [https://www.python.org/dev/peps/pep-3119/#rationale 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. atm i got this working for all tests in `template_tests`, but still need to figure out why some more complex tests fail. so, i could need some feedback at this point before i continue. one question is whether access to non-mappings via `__getitem__` should be supported as last resort with a deprecation warning. two related issues came up while working on it: 1) i didn't research why this was implemented, but the possiblity to lookup attributes on context objects is rather ambigious imo. could this design decision be reverted? (sidenote: using `SimpleNamespace` objects as context seems reasonable though, and they can easily be converted to a mapping with `vars`.) 2) it seems to me that `django.template.context.Basecontext` could be based on `collections.ChainMap` and it may then even allow to simplify the `…._resolve_lookup` implementation. shall i give it a shot while i'm at it?",Bug,assigned,Template system,dev,Normal,,,,Someday/Maybe,0,0,0,0,0,0